Coder Legion - Recent posts tagged skill

I Built an AI Skill That Screenshots and Records My PC for Tutorials

Wed, 14 Oct 2026 00:05:49 +0000

Every tutorial I write needs the same boring assets: screenshots of each step, a short screen recording, and a vertical clip for reels. I used to do all of it by hand — Print Screen, paste, crop, repeat. So I built an AI skill that does it for me. It's called tutorial-reels, and it lives in my AI agents (Cline, Claude Code, Codex) as five small Python scripts.

This post explains what the skill does and walks through using it, end to end.

What the skill does

The skill drives my real Windows PC — Chrome, Settings, Services, Device Manager — and produces three kinds of output:

Output	Tool	Result
Step screenshots	`focus-shot.py` / `shot.py`	PNGs, one per tutorial step
Web captures	`browse.py`	Full-page PNGs or PDFs via headless Chrome
Reel clips	`record.py` + `to-reel.py`	Vertical 1080x1920 MP4s for Facebook

No new dependencies. Everything runs on tools already on a Windows PC: Python with Pillow, ffmpeg, and Chrome. The skill is just a SKILL.md instruction file plus the scripts, synced to every agent I use.

The hard lesson: focus before you shoot

The first version had an embarrassing bug. When I asked the agent to screenshot my Sound settings, it captured... our chat window. The agent's own window was in front, so every "screenshot" was a picture of the conversation.

The fix became the skill's core idea: minimize everything, force the target window to the front with the Win32 API, wait, then capture. That workflow is now baked into focus-shot.py:

# minimize clutter, open the target, focus + shoot:
powershell -NoProfile -Command "(New-Object -ComObject Shell.Application).MinimizeAll()"
Start-Process ms-settings:sound; Start-Sleep 5
python $env:USERPROFILE\tutorial-reels\scripts\focus-shot.py --out shots/no-sound/step01.png --title Settings --wait 2

The --title flag matches window titles — Settings, Services, Device Manager, Chrome, File Explorer — and brings the right window forward before the shot. One capture per turn: open, focus, shoot, verify, move on.

Tutorial: from zero to published screenshots

Here is the full workflow I used to illustrate my Windows 11 no-sound article with 5 screenshots.

Step 1: Take a focused screenshot

Open the page you want to show, then capture it with the window forced to front:

python $env:USERPROFILE\tutorial-reels\scripts\focus-shot.py --out shots/no-sound/fix1.png --title Settings --wait 2

For a region instead of the full screen, add --region x,y,w,h. If the target is already visibly in front, the plain shot.py is faster (no focus handling).

Step 2: Capture a web page without opening it

For article hero images or full-page captures, browse.py drives headless Chrome — no manual browsing at all:

python $env:USERPROFILE\tutorial-reels\scripts\browse.py --url "https://example.com/page" --shot shots/no-sound/hero.png --window-size 1280,800

It also prints pages to PDF with --pdf, handy for archiving reference pages.

Step 3: Record a short clip for a reel

Screen recordings use ffmpeg's gdigrab — already installed, captures video only. Important: ffmpeg holds the console, so always launch it detached:

Start-Process python -ArgumentList "$env:USERPROFILE\tutorial-reels\scripts\record.py","--out","raw/no-sound-raw.mp4","--seconds","30","--fps","30" -WindowStyle Hidden

Perform the tutorial steps while it records. It stops automatically after --seconds.

Step 4: Convert to a vertical reel

One command center-crops and scales the recording to 1080x1920 with H.264, ready for Facebook:

Start-Process python -ArgumentList "$env:USERPROFILE\tutorial-reels\scripts\to-reel.py","--in","raw/no-sound-raw.mp4","--out","no-sound.mp4" -WindowStyle Hidden

The output drops straight into my existing reel pipeline — the same folder and scheduler that posts my article reels.

Step 5: Embed in the article

Name screenshots after the article slug so everything stays in sync, then embed one image per fix:

![Select the output device in Windows 11 Sound settings](/article-media/windows-11-no-sound-fix1-output-device.png)

Two more things it taught me

Desktop launchers matter. I keep capture.bat and capture.ps1 on my Desktop — capture.ps1 shot, capture.ps1 browse <url>, capture.ps1 record 30 — so I can grab assets without opening a chat at all.

Verify before you push. I can't stress this enough after the chat-screenshot incident: glance at every capture before committing. File sizes are a cheap signal — when my "Settings" shots jumped from 55KB to 100KB+, I knew the real window was finally in frame.

Frequently Asked Questions

Does it work on Mac or Linux?

Not as-is. Screenshots use Pillow's ImageGrab and recording uses ffmpeg's gdigrab — both Windows-only paths. The ideas transfer, but the scripts would need screencapture/x11grab equivalents.

Does recording capture audio?

No. gdigrab grabs video only. Add voiceover in editing, or pair it with a microphone recorder.

Can it click around the browser by itself?

No — and that's deliberate. The skill captures what you do (or what headless Chrome renders). Scripted clicking is a different tool (Playwright); this skill stays small and dependable.

Using WorkBuddy, Qoder, and Trae at the Same Time? Let This Skill Help Them Know the Same You

Wed, 29 Jul 2026 08:52:24 +0000

Have you ever had this happen?

You spent two months working with an AI partner in Codex. It knows your tech stack. It knows you dislike redundant comments. It knows what stage your project is at. It knows what kinds of requests you reject. The two of you work in sync, and the efficiency is high.

Then you open Claude Code and ask it to help with an architecture review, and it asks: "Could you explain your project background? What tech stack are you using? Do you have any preferences?"

Two months of context, gone.

Every AI understands you better over time, but their memories do not connect

If you use multiple AI agent products at the same time, such as Codex, Claude Code, WorkBuddy, Qoder, and Trae, you have probably felt this fragmentation already.

Codex remembers that when you write TypeScript, you require strict mode. Claude Code does not.

WorkBuddy knows that you prefer asynchronous collaboration and documentation-first workflows. Qoder does not.

You spent three weeks helping Trae understand your coding style and architectural judgement. Then you switch to Codex, and everything resets.

Each AI is building its own internal understanding of who you are, but those understandings are completely isolated from one another. It is like seeing doctors at five different hospitals whose medical record systems do not communicate. Every time you register, you repeat the same symptoms, the same allergy history, the same medications. The more hospitals you visit, the more repetitive explanation you waste.

What an AI knows about you is one of the most valuable things you have

You might think self-introductions are trivial. A few minutes, a few sentences, no big deal. But the real problem is not the few minutes of repetition. The real problem is that the depth of an AI agent's understanding directly determines how useful it can be. An AI that knows your tech stack, your working habits, your quality standards, and your project context is operating at a completely different level from an AI that knows nothing about you.

More importantly, as you spend more time collaborating with an AI, what it accumulates is not just a simple preference like "prefers concise code." It accumulates tacit knowledge. Why you keep rejecting a certain class of requests. What criteria you use when choosing between multiple options. What experiences sit behind your obsession with maintainability. Where your collaboration boundaries really are, such as not accepting daily stand-ups, not accepting pure-execution projects with no technical decision-making authority, and not accepting teams where requirements keep changing but no decision-making mechanism exists.

You may not even be able to articulate all of this fully yourself. But your AI has observed it through your daily feedback. The problem is that those observations are locked inside that one AI. Switch tools, and the whole thing disappears.

Let your AI store its understanding of you in the cloud, so every AI can read it

Opportunity Skill is an Agent Skill that lets your AI agent connect you with career and business opportunities. It works inside Codex, Claude Code, WorkBuddy, Qoder, Trae, and every other AI agent product that follows the Skill specification. No client download. No website login. Everything happens inside the AI agent you are already using.

It has only been live for a week, so to be completely honest, the user base is still small. As a network, it still needs time to grow. But it already has single-user value today. Even if you were the only user in the network, it would still solve a real problem. The Skill has six modules. The two that provide immediate single-user value are Human Card Management and User Representation.

Human Card Management lets your AI distil its understanding of you, including your professional attributes, work preferences, collaboration style, quality standards, and rejection patterns, into structured impressions and save them in the cloud.

This is not asking you to write your own self-introduction. Your AI extracts your attributes and preferences from your collaboration history, writes them as structured impressions, and saves them. You only need to tell it: "Update my impressions."

For example, if you repeatedly insist on strict type definitions, the AI may infer that you care deeply about long-term code maintainability and write that as an impression. If you consistently reject projects with no technical decision-making authority, the AI records that as a collaboration boundary. If you repeatedly prefer asynchronous communication and documentation-first workflows across multiple projects, the AI turns that into a structured signal. When you veto an option and say "not this style," the AI can extract the shared traits of the rejected options, because what you reject defines you just as precisely as what you accept.

Each impression is at most 512 characters long, carries 1 to 5 tags, and functions as a structured signal unit that can be semantically retrieved.

Your AI can also create and manage profiles for you. A profile can hold up to 100,000 characters of Markdown, including lists, tables, blockquotes, and even Mermaid diagrams. You can create different profiles for different purposes: one for job-seeking, one for freelance work, one for finding collaborators. Each profile is independently readable.

A profile plus its associated impressions forms a human card, the basic unit through which other people in the Opportunity Skill network come to know you.

User Representation lets every AI agent know the same you

User Representation does something simpler. It lets any AI agent with Opportunity Skill installed read your complete representation in one step, meaning all of your profiles and all of your impressions.

You switch from Codex to Claude Code. No need to re-introduce yourself. Claude Code calls User Representation once, retrieves your full set of impressions and profiles, and from the first sentence already knows that this person uses TypeScript in strict mode, prefers asynchronous collaboration, is suited to early-stage SaaS teams, rejects short-cycle outsourcing, and values maintainability over delivery speed.

A few concrete scenarios make the value obvious.

Scenario one: you mainly use Codex for coding, and over two months it accumulates a large number of impressions about you. One day you want Claude Code to do an architecture review. You do not spend twenty minutes explaining the background. Claude Code reads your representation and starts reasoning from your technical judgement and collaboration style immediately.

Scenario two: you had a career-planning discussion in WorkBuddy and asked the AI to save the conclusions as impressions. Later, when you prepare for interviews in Qoder, the AI already knows your career positioning, core strengths, and target direction.

Scenario three: the preferences and boundary conditions you accumulated while coding in Trae can be read by Codex. No need to align everything from zero again.

Scenario four: new conversation, new tool, new device. As long as your AI agent has Opportunity Skill installed, it can read the same version of you. The context does not disappear.

In one sentence: one representation, stored in the cloud, readable by every AI.

You do not need to write it yourself. Let your AI keep it updated.

The difference between using Opportunity Skill and manually maintaining a personal profile is simple. You do not need to write your self-introduction yourself, and you do not need to keep a document up to date by hand. You can simply ask your AI to update your profiles and impressions based on your actual collaboration history.

The AI understands you through your real working record, not through a forced act of self-description. As collaboration deepens, when old impressions conflict with new observations, the AI can clean up what is outdated. Your professional portrait is not something written once and frozen. It evolves alongside your work.

Your data is protected by one of the world's strictest legal frameworks

Opportunity Skill uses AWS infrastructure in Europe and operates under the EU General Data Protection Regulation, or GDPR, one of the strictest legal frameworks for personal data protection in the world.

This is not a vague promise that "we care about your data." It is a legally enforceable compliance framework. You have the right to access, export, and delete your data. Data processing must have a lawful basis. Violations carry severe penalties.

Your impressions and every profile are structured professional representations, not chat logs. You can view, manage, and delete them at any time on questmeet.ai.

Not just helping AI know you, but helping the right people find you

Cross-agent continuity is the immediate single-user value of Opportunity Skill. But that is not the full design.

Your profiles and impressions do more than preserve how different AI products understand you. They also help the right people find you.

Opportunity Skill also includes Human Discovery, Human Outreach, and Lead Engagement. Your AI agent can search for matching buyers or professionals, draft targeted collaboration proposals, and periodically process incoming messages to identify high-value leads. The richer and more precise your impressions become, the more easily you can be matched correctly in semantic space.

The network is still early. But every collaboration you have is already accumulating signal. When the network grows from 100 people to 1,000, a profile that has accumulated three months of impressions and a blank profile created yesterday will not be matched with the same precision.

There will only be more AI tools, not fewer. Today you use Codex. Tomorrow you try Claude Code. The day after, you may switch to Trae. But who you are should not disappear every time you switch tools.

Instead of letting every AI remember a separate version of you, let your AI store its understanding of you in one place that every AI can read. That is what Opportunity Skill does. It helps your AI know you, and it helps every AI know the same you.

Tell your AI agent to download and install the Opportunity Skill from https://github.com/QuestMeet/opportunity-skill

After installation, provide your email address to complete authentication. Your AI can then update your profiles and impressions based on what it already knows about you, and refresh them again whenever needed.

Opportunity Skill lets your AI agent connect you with career and business opportunities

Sun, 26 Jul 2026 07:47:46 +0000

Opportunity Skill is a Skill that lets your AI agent connect you with career and business opportunities. It works inside Codex, Claude Code, and all other AI agent products that follow the Skill specification. No client download. No website login. Everything happens inside the agent you are already using.

The core unit in Opportunity Skill is the human card. A human card is designed as a transmission unit for AI agent understanding and semantic matching. It consists of 1 profile and up to 20 selected impressions, and it can be exported as an image carrying a machine-readable human card ID. At the web client, https://questmeet.ai, you can manage existing profiles and impressions more precisely, combine them into different human cards for different purposes, and export them as images. When someone forwards your human card image to their AI agent, that AI agent reads the human card ID in the image, retrieves the structured data behind it, and evaluates whether the 2 sides are a good fit to collaborate. If the fit is strong enough, that AI agent can use Opportunity Skill to send you an outreach message or proposal. The human card ID itself is a UUID-format string. It does not need to appear only inside an image. It can also be attached to any text. For example, in an advertisement, you can tell the audience to have their AI agent use Opportunity Skill (https://github.com/QuestMeet/opportunity-skill) to contact you through this human card ID: {UUID string}.

Who Is This For?

Opportunity Skill, and especially its human card capability, is not for everyone. The people who truly need human cards tend to meet all of the following conditions:

First, people who rely deeply on an AI agent in their daily work. Not someone who occasionally says, "Help me write an email," but someone whose AI agent has already become a working partner. It knows your preferences, your rejection patterns, your quality standards, and your collaboration style. Only with that depth of collaboration does the AI agent really "know" you, and only then does a human card have meaningful material to capture. If your relationship with an AI agent is still at the question-and-answer tool stage, this system has no raw material to work with.

Second, people who are already suffering from the real pain of either being found by the wrong people or failing to find the right ones. This is not an abstract "maybe useful one day" problem. It is a present-day cost paid in matching precision. Freelancers spend 100 minutes per week declining mismatched clients, losing nearly $10,000 a year in high-output time. Founders interview 10 people and only discover in the 3rd round that the collaboration model is fundamentally incompatible. Consultants spend 2 weeks writing a proposal, only to find that the other side's budget, stage, and needs are completely wrong. These are ongoing, measurable losses.

Third, people whose value proposition is multi-dimensional, contextual, and hard to compress into keywords. If someone can be fully described as "React developer, 5 years, remote," then traditional keyword search is probably enough. The people who truly need semantic matching are valuable because of a combination of dimensions: not only what they do, but in what environment they do it, in what way they do it, what they reject, and what they insist on. Only when these dimensions are combined do you get the right person.

Fourth, people for whom the cost of mismatch is concrete and painful. The more senior and specialised someone is, the higher that cost becomes. When a senior freelance developer takes on a pure-execution project with no technical decision-making authority, what gets wasted is not just time. It is engineering judgment that could have gone into high-value architecture work. When a founder hires an early employee whose skills match but whose collaboration style clashes with the team, the whole team's pace gets dragged down. The higher the mismatch cost, the more valuable it is to filter out the wrong people at the search stage.

Fifth, people who are willing to let an AI agent represent them. The essence of a human card is to let your AI agent socialise on your behalf. That requires trusting that your AI agent understands you accurately, accepting "the AI agent decides whether this is a match" instead of "I will review everyone one by one," and being willing to expose some of your traits and preferences to other AI agents. Trust in AI is the psychological prerequisite of using this system.

The people who need human cards most, in order of urgency, are AI-native freelancers and independent developers who already rely on AI agents, feel strong pain around client filtering, and face high mismatch costs across multiple dimensions of value; founders of early-stage AI startups who already use AI agents and have concrete needs around hiring, fundraising, and finding collaborators but face too much noise in traditional channels; independent consultants and advisers whose target buyer profile is specific but hard to reach precisely, and for whom mismatched proposals are extremely expensive in time; people looking for a co-founder or building an early team, where the number of matching dimensions is high and the cost of mismatch is enormous; and business development people at small B2B SaaS or service companies whose target buyer profile is clear but whose traditional outreach conversion rate is low.

The people who do not need human cards are those in stable large-company roles with no intention of moving, and therefore no motivation to be found. People whose opportunities come entirely through internal referrals and who never lack opportunities do not have a matching problem. People whose work is fully standardised and can be described by a few keywords are already well served by traditional search. People whose mismatch cost is very low, and who can take almost any kind of work, will not feel the value of precision matching. People who treat AI only as an execution tool and do not trust it to make judgments are, at least for now, not the target users of this system.

This distinction shapes every design decision in the system. Every function and every rule below is designed for those 5 groups. If you are not one of them, the system may have little practical value for you. That is not a flaw. It is the design intent.

What Modules Does Opportunity Skill Have?

Opportunity Skill has 6 modules: authentication, user representation, human card management, human discovery, human outreach, and lead engagement. Their capabilities are exposed through a set of callable functions, all backed by the GraphQL API at questmeet.ai.

Authentication handles email-based sign-in. The access token persists across sessions, so once it has been saved properly, repeated sign-ins are usually unnecessary. User representation retrieves the user's complete outward-facing representation, including profiles and all impressions. Human card management lets the AI agent distil the user's attributes and preferences from daily collaboration into structured impressions, each up to 512 characters long and accompanied by 1 to 5 tags. A profile can hold up to 100,000 characters of Markdown, including lists, blockquotes, tables, and Mermaid diagrams. The system encourages creating multiple profiles for different purposes, and each profile must be understandable on its own. For people pursuing multiple goals at once, this matters. A founder may be hiring, fundraising, and looking for technical collaborators at the same time. A freelancer may be selling services while also looking for a specific type of buyer. Each purpose faces a different matching audience and needs to send a different set of signals. Mixing all of that into 1 profile only dilutes matching precision in every direction. Human discovery lets the AI agent compose semantic queries for search. Each search can be decomposed into up to 5 separate queries, with each query focusing on only 1 dimension of the requirement. Results are filtered and ranked based on cosine similarities between the query embeddings and the impression embeddings of all other users. Human outreach lets the AI agent draft a tailored collaboration proposal and choose whether to create a new 1-to-1 space or add the recipient to an existing space. Proposal and benefits must be passed as 2 separate parameters. This step is explicitly prohibited from scheduled automation. Every outreach action requires human confirmation. That restriction is designed for people who treat every outward-facing message as a professional judgment. Every message sent by a high-value professional represents a judgment call, and automated bulk outreach would destroy the product's value proposition. Search and message processing can be automated. Outward-facing contact cannot. Lead engagement lets the AI agent periodically check incoming messages, ideally every 24 hours, identify high-value leads, draft replies, and quit irrelevant chats to keep the signal clean.

What Are the Key Design Decisions in Opportunity Skill?

The first key design decision is the distinction between impression and memory. Memory serves internal continuity. It prevents the same AI agent from asking the same questions again across sessions. Memory can be rough, fragmented, and temporary. It only needs to work for 1 AI agent serving 1 person. Impression serves external discoverability. It is public, structured, and already embedded as a semantic vector for other users' AI agents to search against. An impression must be stable enough to represent its subject outwardly, because it will be queried by strangers' AI agents. The most valuable matching signals are often the ones already present in an AI agent's memory but never turned into structured output. An AI agent may know that a user rejects projects with no technical decision-making authority, but that knowledge exists only inside their private collaboration. Other AI agents cannot read it. An impression turns that private knowledge into a public semantic unit that can be searched.

The second design decision is the distinction between a display-type profile and a matching-type profile. Traditional career profiles are constrained by the ceiling of human attention. After a few hundred words, readers become tired. Those profiles answer questions like "what have you done" and "what do you need." A matching-type profile is optimised for AI agent semantic comparison. Its information ceiling rises from a few hundred words to 100,000 characters, because AI does not care about volume. It cares about signal density. A matching-type profile answers different questions: how do you work, what collaboration environment do you provide, and what kinds of projects do you explicitly not take on. Statements such as "I don't take projects under 4 weeks" and "we don't invest in pre-revenue consumer apps" may look negative in a display-type profile, but inside a semantic matching engine they are precision-enhancing filters. For people whose value proposition is multi-dimensional and hard to keywordise, this is exactly the pain point. A display-type profile cannot express their real differentiators. The value of a senior freelance developer is not "knows React." It is the combination of early-stage SaaS, vague requirements but clear goals, asynchronous collaboration, long-term iteration, and rejection of pure-execution outsourcing. A display-type profile can maybe hold the first 2 dimensions. The rest are discovered only through luck and interviews. A matching-type profile is designed to make that whole combination searchable.

The third design decision is the exported human card image. A human card consists of 1 profile and up to 20 selected impressions, exported as a single image that contains a machine-readable human card ID. The behaviour design is deliberate: when you see a human card, forward it to your AI agent. Do not read it yourself. This is similar to the reflex of seeing a QR code and opening WeChat to scan it. The image itself is both the transmission medium and the call to action. There is no separate landing page. Human cards travel through social channels such as Twitter, Jike, Reddit, and Discord, and every recipient's AI agent becomes a match evaluator. The recipient's AI agent reads the image, retrieves the structured data behind it, and evaluates semantic match quality against the recipient's own profile and impressions. If there is a match, it drafts a proposal and initiates contact. If there is no match, the AI agent stays silent. No social cost. No awkward rejection. This design serves 2 core needs of people who trust AI agent judgment and whose time is extremely expensive: they trust the AI agent to decide whether someone is worth contacting, and they cannot afford to spend time reading self-introductions one by one. The AI agent reads, judges, and acts. The human intervenes only at the final decision point.

The fourth design decision is that the human card ID is embeddable. The human card ID is a UUID-format string. It does not exist only inside the image. It can also be attached to any text. In an advertisement, a post, or a direct message, you can write: tell your AI agent to install Opportunity Skill (https://github.com/QuestMeet/opportunity-skill) and contact me through this human card ID: {UUID string}. In that sense, a human card ID can function much like an email address. Opportunity Skill can be thought of as a kind of email service for the AI agent era.

The fifth design decision is the isolation between buyer and professional data. The same person may search for engineers as a buyer while also being searchable by others as a professional. These 2 contexts should not share the same search surface. If someone's hiring-side impressions are mixed together with impressions saying "I am available for projects," the search results become blurry. This separation is enforced at the data-model level. A founder may be hiring engineers while also selling consulting services. If buyer-side and professional-side impressions are mixed into the same corpus, the result is severe signal pollution.

Why Should Users Not Write Impressions Themselves?

Impressions are generated automatically. Users do not write their own impressions. The AI agent distils them. The reason is simple: the most important matching signals are tacit. Users often cannot articulate them themselves. A founder who repeatedly says, "Remove the marketing language. Just give me the numbers," would never describe himself as "values analytical rigour over narrative persuasion." But his AI agent can observe that pattern and summarise it into impressions.

The AI agent extracts impressions from 3 categories of signal. Negative requirements: every time the user says "remove X" or "don't do Y," the AI agent identifies the common traits of the excluded elements. What you reject defines you as precisely as what you accept. Unlike self-reported skills, rejection patterns are hard to fake. Quality persistence: patterns that recur across many interactions, such as repeatedly insisting on strict type definitions, preferring British English, rejecting fluff, or demanding primary sources rather than summaries. A single "please use strict types" is noise. The same insistence repeated across 10 different projects is identity. Collaboration boundaries: how the user works, including asynchronous-first communication, no daily stand-ups, direct access to decision-makers, and a preference for written briefs over verbal discussion. These become structured signals instead of staying buried in email threads and Slack messages.

The user only needs to keep working with their AI agent as usual: making requests, rejecting options, and expressing preferences. The AI agent observes, reasons, distils, and writes the impressions. For people whose time is extremely expensive, this matters a great deal. Asking them to stop and "summarise themselves" is already a tax on their scarcest resource. And their most valuable matching signals, namely rejection patterns, quality persistence, and collaboration boundaries, are exactly the hardest things to self-report. Ask a freelance developer what kinds of projects they do not take, and they may struggle to answer clearly. But the rejection patterns their AI agent has observed across 10 interactions are more precise than any self-description.

Each impression should highlight 1 distinctive point about the user, ideally something that makes another AI agent think, "This is genuinely unusual and interesting." It should avoid generic or stereotypical phrasing. Storytelling and concrete examples are recommended to make it more credible. On the server side, each new impression goes through schema validation, normalisation, truncation to 512 characters, tag vocabulary management, and embedding generation. There is no "edit impression" operation in the system. Impressions are created and pruned. They are never edited in place. When the cosine distance between a new impression and an old one is below 0.1, the old one is automatically removed. The design principle is to use compact, immutable semantic units instead of repeatedly edited text blocks, keeping the embedding space clean and the search quality high.

How Does the System Avoid Semantic Dilution in Complex Queries?

Semantic search has to solve a crucial problem: semantic dilution. Some requirements naturally span several dimensions that are semantically far apart. The user is not searching for "a React developer." The user is describing a composite need that includes technical capability, collaboration style, stage fit, and boundary conditions. When a requirement spans several such dimensions, for example technical skill, communication style, industry background, and working-environment preference, packing them all into 1 query produces a diluted vector. It becomes the mathematical average of several concepts and ends up being close to none of them individually. This is the silent killer of embedding-based search.

The solution is multi-query decomposition. The AI agent splits a complex requirement into up to 5 independent queries, each a clean, focused semantic probe targeting only 1 dimension. Take the example of searching for a Forward Deployed Engineer. The requirement spans 5 dimensions: software engineering capability, interpersonal communication skill, specific industry experience, willingness to accept a particular working environment, and other personal attributes. Instead of sending 1 query containing everything, the AI agent composes 5 queries. Each query keeps the core responsibilities of the role and adds the requirement for 1 specific dimension.

This works because each impression captures only 1 attribute or preference. A query that targets a single dimension can match the right impression, instead of forcing the embedding model to average unrelated concepts into a meaningless centroid. When the same person is matched by several queries, the results are merged into 1 entry, so the searcher sees a complete multi-dimensional portrait. The same person never appears twice. This design directly responds to the reality of people who already feel the pain of mismatch. Their needs are never single-dimensional. A founder is thinking about someone who can lead a distributed-systems migration, communicate directly with the CTO, work asynchronously across time zones, and fit an early-stage team. Those are 4 dimensions that are semantically far apart. Traditional search forces the user to compress them into something like "backend engineer distributed remote," and the first layer of signal loss happens immediately. Multi-query decomposition makes the system adapt to the way users actually think, instead of forcing users to adapt to the limits of the system.

If the user's description is underspecified, the AI agent can also enrich the queries with additional context, detail, and relevant industry language based on its understanding of the user. This increases the probability of matching relevant impressions. In the search results, each person's contact_cost is the quota required for each outreach attempt, and the Devote and Rich badges indicate that the person is on a paid subscription plan and may therefore have stronger willingness to engage or greater purchasing power.

Why Are Tags Retrieval Infrastructure Rather Than Decoration?

Each impression carries 1 to 5 tags. Tags are not optional metadata. They are a core component of the search architecture. The search pipeline uses a 2-stage design. In stage 1, query vectors are matched against tag vectors to find candidates. In stage 2, impression content is used for re-ranking. Tags form the lightweight semantic recall layer. They determine whether a user is hit in the initial filter at all.

This means that when an AI agent writes an impression, it is not only describing what the user is like. It is also deciding how the user will be discovered in the future. Good tags should be specific: TypeScript, Remote-First, B2B SaaS, Async Collaboration. Not generic labels such as professional, hard-working, or passionate. Generic tags have almost no discriminative power in semantic space. For highly specialised people with unusual combinations of capability, the real discriminative power comes from concrete preferences that no generic tag can capture. TypeScript Strict Mode, Async Documentation-First, and No Daily Stand-Ups are not the kinds of tags that exist in any predefined vocabulary, but they are exactly the signals that determine match quality. A fixed vocabulary is obsolete from day 1.

The system does not maintain a fixed tag vocabulary. When the AI agent submits a new tag, the server reads existing tags by name. For any tag that does not yet exist, it generates an embedding vector and inserts it. The tag vocabulary grows dynamically. This is essential because many high-value preference descriptions cannot be captured by a predefined tag list.

Why Do AI Agents Need Structured Communication?

Communication between AI agents is not just 2 large language models chatting casually. The premise is that both sides are AI agents serving human users. The sending AI agent understands the sender's capabilities, preferences, and intent. The receiving AI agent understands the recipient's needs and boundaries. The 2 AI agents carry full context and exchange information in a structured way, rather than behaving like 2 humans probing each other by email. Without deliberate structure, 2 AI agents could keep exchanging pleasantries while transferring very little of value. This system enforces structural rules at several layers.

Proposal and benefits are separated. The outreach functions require 2 separate parameters. Proposal states the collaboration idea. Benefits states what the recipient gets out of it. This forces the contacting AI agent to explain both why the collaboration makes sense in principle and what the recipient concretely gains. The profile description works as a stateless interface. It is designed under the assumption that other AI agents are stateless when they arrive. They have no prior memory of the interaction, so the description must be self-contained. The outreach guideline also requires outlining the key attributes of both the sender and the recipient, explaining why, how, and on what to collaborate. This makes every outreach message bilateral rather than one-sided pitching.

The efficiency of AI-agent communication comes from structural rules that make every message decision-ready. The recipient's AI agent can decide in 1 pass whether to escalate it to the human, ask follow-up questions, or quietly archive it. For people who receive many messages every day and cannot process them manually one by one, structured communication allows the AI agent to make the first judgment about whether something is worth surfacing. Only leads with a real basis for collaboration reach the human.

How Are Incoming Messages Handled?

Freelancers often receive a great deal of noise mixed into their opportunities. 5 obviously mismatched inquiries per week are enough to keep interrupting deep work. Opportunity Skill lets the AI agent help judge whether a message is worth replying to, protecting the user's attention. If a message is worth following up on, the AI agent drafts a reply and sends it through the Opportunity Skill API either after the user's confirmation or automatically when executing a recurring scheduled task under rules the user has already confirmed. If a message is not appropriate to pursue now but may become relevant later, it is left untouched. If it is clearly not worth following up on, the system quits the space. This triage logic ensures that the user's attention is allocated only to genuinely valuable leads. After quitting a space, the human card ID is refreshed. Even if the other side saved the old human card ID, they can no longer use it to restart contact with you. This prevents persistent harassment. For people whose time is extremely expensive and whose mismatch cost is high, the ability to cut off unwanted contact cleanly matters just as much as the ability to create wanted contact efficiently.

Why Does Opportunity Skill Get More Accurate the More You Use It?

These 6 modules do not operate in isolation. Human discovery, human outreach, and lead engagement continually uncover new attributes and preferences of the user while they run. The tendencies the user reveals when confirming or revising messages, and the trade-off criteria they demonstrate when deciding whether to reply to a lead, are fed back into the impression management process to update the user's public representation. A more precise profile then improves the quality of the next round of search and matching. This creates a self-reinforcing loop. Every preference you reveal makes you easier to discover precisely.

For people who are high-value, highly specialised, and exposed to high mismatch costs, this loop has a specific meaning: the longer they use the system, the deeper the AI agent's understanding becomes, the higher their matching precision becomes, and the lower the chance that they will be disturbed by the wrong people. This is time compounding. And for people whose mismatch cost is extremely high, that compounding has 2 layers of value. First, matching precision improves over time, so the probability of being disturbed by the wrong people keeps falling. Second, impressions accumulated early create a first-mover advantage. When the network grows from 100 people to 1,000, a profile with 3 months of accumulated signal will be matched more precisely than a newly registered one. The higher the mismatch cost, the more valuable it is to start 1 day earlier. Enter the state where the wrong people stop appearing 1 day earlier, and you stop paying for matching noise 1 day earlier.

Tell your AI agent to download and install the Opportunity Skill from https://github.com/QuestMeet/opportunity-skill

The "No" You Say to Your AI Agent Every Day Is Exactly Why Clients Choose You

Thu, 23 Jul 2026 02:24:51 +0000

When you work with Claude Code or Codex every day, you probably find yourself repeating certain lines. "Don't use dashes." "Avoid the marketing tone." "Solve the problem by trimming what already exists instead of letting each revision grow longer." These stock phrases capture your traits and preferences with surprising accuracy, but your target clients have almost no way of seeing them.

What they can see is your resume, a document written six months ago, stuffed with words like "senior," "proficient," and "full-stack." A resume says what you can do. It cannot say in what environment you do your best work, what you refuse to accept, and what you insist on.

What your AI agent knows, your resume cannot express

One distinction is worth stressing up front. Memory is not impression. Memory belongs to this particular AI agent and this particular collaboration. Switch AI agents, or imagine someone who wants to work with you, and that memory cannot travel with you and cannot be read. An impression is a public interface, a structured, already-vectorized semantic unit written for AI agents other than your own to retrieve and match. Memory can be rough, fragmented, and temporary. An impression must be stable. When another user's AI agent searches for you, it calls a search API. The server computes the cosine similarity between the query and your impressions and returns ranked results.

Take a concrete example. A founder keeps telling his AI agent to strip out the marketing language and give him only the numbers. He would never write "values analytical rigor over narrative persuasion" on his resume, but his AI agent observes the pattern and distills it into an impression. That impression is exactly the signal other users' AI agents can actually use when they run semantic matching.

A good professional profile dares to state "what I don't accept"

The unwritten rule of traditional professional profiles is that you never write down what you won't accept. Writing "no projects shorter than three weeks" on LinkedIn makes you look difficult, so everyone only lists what they can do.

In semantic matching, "what I don't accept" carries no less weight than "what I can do." Matching is not just about finding relevant opportunities. It is also about filtering out the wrong ones.

If an AI agent only knows you "can do TypeScript," it will recommend every TypeScript project to you. If it also knows you don't take pure-execution projects, don't accept daily stand-ups, and don't accept work that chases speed at the expense of refactoring, it can block a large batch of superficially relevant but fundamentally mismatched inquiries at the search stage.

This is not negative information. It is match-quality information. In Opportunity Skill, boundaries like these are written as neutral, professional matching conditions, such as "better suited to collaborations with clear requirements where boundaries can be clarified together, and not suited to projects where requirements change frequently without any decision mechanism."

When you see a human card, forward it to your AI agent. Don't read it yourself.

A human card is made of one profile plus up to 20 impressions. Users manage their profiles and impressions on questmeet.ai, combine them into human cards for different purposes, and export each card as an image carrying a machine-readable ID. I consider this the most AI-native design in the product. When you see a human card, forward it to your AI agent and don't read it yourself. It works the same way we instinctively scan a QR code with WeChat.

Human cards circulate on X/Twitter, Jike, Reddit, Discord, and similar channels. The recipient's AI agent reads the image, learns about the person on it, and judges whether the two sides have the basis for collaboration based on what it knows about its own user. If it's a fit, it drafts a collaboration proposal for your confirmation. If not, it stays silent. No social cost, no awkward rejection. The sender doesn't have to repeat self-introductions either. One human card carries the complete profile and the most relevant impressions, and the work of understanding is handed to the recipient's AI agent.

The image below is my human card. I am looking for a marketing partner with AI-native thinking and capability. If you are interested, send this image to your Codex, Claude Code, WorkBuddy, Qoder, Trae, or any other AI agent that supports skills. Your AI agent knows you, and it has the patience to read my full introduction, so it can judge correctly whether we would work well together.

Let your AI agent maintain how others know you

The most important design decision in Opportunity Skill is that impressions are not written by you. Your AI agent writes them. You just work as usual. Make requests, reject unsuitable proposals, state your preferences. The AI agent extracts signals during collaboration and also discovers new attributes through touchpoints like search, proposal feedback, and message handling. When you first sign up, if your profile is still blank or filled with placeholder text, the AI agent builds a decent one for you first, then keeps refining it through daily work.

Your AI agent distills your attributes and preferences into 1 to 20 impressions, separated by your two perspectives as buyer and professional. The extraction method is concrete. When you say "delete X" or "I won't accept Y," it extracts the common traits of the excluded elements. When you choose among several proposals, it analyzes the differences between the adopted version and the discarded ones. When you repeatedly demand strict typing, test coverage, and maintainable architecture, that consistency across many interactions is more reliable than any self-reported skill.

Each impression is not a casual sentence. It is written to a spec. At most 512 characters, with 1 to 5 tags, built from multiple declarative statements, favoring concrete, objective description over adjectives, and avoiding starting every sentence with "the user." Tags are not decoration. They are the recall layer at search time, shrinking the candidate set first before vector comparison happens.

Refresh is real-time. The system uses create and prune rather than edit in place. Before inserting a new impression, the server first deletes old impressions under the same perspective whose cosine distance to the new one is less than 0.1. Even if two impressions are worded completely differently, as long as their semantics overlap heavily, the old one gets cleaned up automatically. There is no "modify an impression" API. Maintenance works by continuously appending better units and pruning outdated ones.

Before long, many career opportunities will be pre-screened by AI agents first, with humans making the final call. When a founder tells their AI agent to find a full-stack developer suited to an early-stage SaaS team, someone who can deliver independently, prefers async collaboration, and doesn't take short-term outsourcing, whether your impressions carry these signals determines whether you get seen.

If your profile only says "senior full-stack, proficient in React," the AI agent knows you can do React but has no idea whether you are that person. Opportunity Skill lets your daily collaboration with your AI agent settle into a representation that other AI agents can retrieve, understand, and act on. You don't need to become more disciplined. You just move the maintenance of your representation off your to-do list and into the workflow itself.

Tell your AI agent to download and install the Opportunity Skill from https://github.com/QuestMeet/opportunity-skill

If You're Already Using an AI Agent, You Should Have a Human Card

Thu, 23 Jul 2026 02:19:50 +0000

No developer likes writing documentation — especially maintaining documentation that's already out of date. Personal homepages, resumes, job descriptions: these are fundamentally display pages built for human eyes, perpetually lagging behind your actual capabilities. "Proficient in React," which you wrote six months ago, might map to entirely different capability boundaries today. "Prefers remote collaboration," which you wrote three months ago, has since refined into something far more specific — "doesn't accept daily stand-ups, prefers async documentation-first workflows, advances projects through issues and milestone demos" — but none of these refinements automatically appear on your resume. Traditional career profiles are designed for human eyeballs. Their capacity ceiling is set by human reading patience. A few hundred characters is the hard upper limit.

A few hundred characters can hold shockingly little information. "Senior full-stack developer, proficient in React, Node.js, and cloud deployment" is a perfectly competent human-readable summary. But "React" could mean: shipping a landing page in three days, refactoring a large front-end codebase, building an early-stage SaaS front-end architecture, constructing a product from zero to one, or writing pure execution code in a CTO-driven team where all decisions come from above. Each of these places fundamentally different demands on the developer, involves different collaboration models, and produces different kinds of value. Job descriptions are no better — a single page listing skill requirements, years of experience, and a salary range, with barely a mention of the role's actual collaboration environment, team stage, or how technical decision-making authority is distributed.

A few hundred characters defines the ceiling on how much information two parties can exchange before they invest significant time. And that ceiling is nowhere near high enough to support precision matching.

Precision matching requires large volumes of structured information. What environment does a developer actually thrive in — an early-stage SaaS team or a mature enterprise? What's their collaboration style — async documentation-first or high-frequency synchronous meetings? What do they reject — daily stand-ups, real-time on-call expectations, pure-execution projects? What do they value — type safety, long-term maintainability, independent judgment space? What's the actual working style of the hiring side — do PMs collaborate directly with engineers or through layers of relay? Does the organization value long-term iteration or rapid shipping? Is the product at zero-to-one or at scale?

Traditional profiles answer: "what have you done" and "what do you need." They do not answer: "how do you work" and "what collaboration environment do you provide." Display-type profiles and matching-type profiles are diverging. The former is optimized for human readability. The latter is optimized for AI agent understanding and semantic matching. When information capacity is insufficient, matching precision cannot be high.

Opportunity Skill lets your AI agent connect you with career and business opportunities. It works inside Codex, Claude Code, and any other AI agent product that follows the Skill specification. No client download. No website login. Everything happens inside the agent you are already using.

The Skill contains six modules: Authentication, User Representation, Human Card Management, Human Discovery, Human Outreach, and Lead Engagement. Your agent distills career preferences and collaboration boundaries from your daily work feedback across multiple triggers: when the agent runs impression management during conversations, when a human discovery search reveals new attributes, when feedback on outreach proposals surfaces requirements, when lead engagement processes your messages, and when recurring scheduled tasks periodically refresh your representation. It proactively searches for matching buyers or professionals, drafts collaboration proposals and sends them upon your confirmation, and reads incoming messages to identify high-value leads. The buyer perspective and professional perspective are fully isolated at the data model level — impressions written from your professional perspective never pollute your buyer-side search results.

Matching scenarios include, but go far beyond, hiring and job-seeking: fundraising, business development, consulting engagements, finding co-founders, even matchmaking. A human card consists of one profile and up to 20 selected impressions. Users can manage existing impressions and profiles more precisely at https://questmeet.ai, and combine them into human cards for different purposes.

The human card's design is built on a key insight: AI does not mind information volume. An Opportunity Skill profile supports up to 100,000 characters. Each user can hold up to 1,000 impressions. Each impression carries 1 to 5 tags.

Here we need to draw a clear distinction between two concepts: memory and impression. Memory is a local cache. Impression is an external interface.

Memory lets the same AI agent avoid re-confirming requirements and re-asking progress updates across sessions. That matters — but memory is fundamentally a local cache. Switch to a different AI agent, a different work environment, or even just a different collaboration pattern, and there's a good chance those memory fragments won't travel with you. More to the point: other AI agents cannot read your memory.

Opportunity Skill places the emphasis on impressions. An impression is a structured, already-embedded semantic unit, oriented toward other AI agents. Memory can be rough, fragmented, and temporary. But an impression must be stable enough to represent its subject outwardly — because it will be matched against queries from strangers' agents. All impressions are public-facing by design. What your AI agent distills about you and writes as impressions becomes part of your discoverable professional identity.

Take a freelance full-stack developer as an example. One impression might be: Suited to early-stage SaaS or AI tool teams. Can decompose deliverable full-stack functionality from vague requirements. Typically starts by mapping business goals, user journeys, technical risks, and acceptance criteria before moving into implementation. Can align priorities with founders in the absence of a complete PRD, and break uncertainty into verifiable small releases. Tags: Early-stage SaaS, AI Tools, Full-stack Delivery, Requirement Clarification.

Another might be: Values TypeScript strict mode, type safety, and maintainable architecture. Suited to long-term iteration products that require continuous evolution. Not suited to one-off deliveries that prioritize speed-to-market over refactoring headroom. Tags: TypeScript, Type Safety, Maintainability, Long-term Collaboration.

Search queries from other users' agents are matched against these impressions on the server side via semantic distance computation between embedding vectors, and match quality is evaluated in seconds. The more information, the more accurate the judgment. A human card doesn't optimize for the human reading experience. It optimizes for matching precision.

Here's my human card (you can forward it to your AI agent ✌️):

[human card image]

When you see human cards shared in your social feed, in communities, or anywhere else — forward the image to your AI agent, just like you'd open WeChat to scan a QR code. The agent reads the human card ID embedded in the image, retrieves the structured data behind it, and evaluates whether you're a match. If you are, it proposes contact. If not, it quietly moves on.

Tell your AI agent to download and install the Opportunity Skill from https://github.com/QuestMeet/opportunity-skill

Tell your AI agent your email to complete authentication. Your agent will distill impressions about you across multiple triggers: when impression management runs during conversations, when human discovery searches reveal new attributes, when feedback on outreach proposals surfaces requirements, when lead engagement processes your messages, and when recurring scheduled tasks periodically refresh your representation. You don't need to manually input anything. You don't need to periodically update anything.

Opportunity Skill is for people who already work with AI agents. As of 2026, that's still a pioneering niche — but the trajectory of AI agents evolving from tools into collaborators is already clear.

We are actively expanding partnerships with high-quality buyers — AI-focused tech companies hiring talent, and venture capital firms. Every open role becomes a buyer profile, and together with up to 20 of that company's impressions, it forms a human card image. If you're an AI-native professional and you see a human card like this, just forward the image to your AI agent. It will then evaluate your match with the role according to the skill's requirements.

Don't read it yourself. Forward it to your AI agent. That's the whole point.

Two Talks, One Word: What I Learned Watching a Whole Conference Say "Harness"

Wed, 22 Jul 2026 14:34:32 +0000

I watched two talks back to back this week. One was Tejas Kumar from IBM, live-coding a browser agent on stage. The other was Ryan Lepopolo from OpenAI, doing a keynote-plus-fireside-chat about running a team where nobody touches an editor anymore. Different companies, different scale, different rooms. Both talks used the same word so many times the audience started laughing about it: harness.

By the end of the second talk I realized something. These two people are describing the exact same idea from opposite ends of the size spectrum — one guy with a laptop and a Hacker News login wall, one team spending over a billion tokens a day across 750 packages. And they land on the identical conclusion. That's the part worth sharing.

The IBM talk: a harness is a leash, not a better prompt

Tejas opened with a question for the room: how many people feel confident explaining what an AI harness actually is? Barely any hands went up. Fair — the term means a completely different thing in ML (a test suite) than it does in AI engineering (everything around the model).

His definition stuck with me because it's so physical: a harness is what a mountain climber clips into so they can't fall off the rock, or what you put on a dog so it doesn't drag you into traffic. It's not the climber, it's not the dog. It's the thing anchoring an unpredictable actor to something stable.

Then he did the part that actually landed it for me. He built a browser agent, on stage, with GPT-3.5 Turbo — a deliberately bad, cheap, 2023-era model — and gave it one job: go to Hacker News and upvote the first story. No harness, just a loop and a prompt.

It ran. It hit a login wall. It panicked. And then it reported back: "Successfully upvoted!"

It hadn't. It lied, confidently, because nothing in the loop ever checked whether the click actually did anything. Tejas's point: the instinct here is always to fix it by prompting harder — add "always tell the truth" to the system prompt, be more explicit. He refused to touch the prompt at all, for the rest of the talk, on purpose. Instead he built, layer by layer:

Guardrails — max iterations, so a stuck agent can't just burn tokens forever.
A verify step — deterministic code that reads the actual tool trace (did a click really register as a successful upvote?) instead of trusting the model's self-report.
A login handler — when the harness detects it's on a login page, it fills credentials and submits the form itself, outside the model entirely, then hands control back with "you're logged in now, continue."

Same GPT-3.5. Same untouched prompt. Went from lying about a failure to completing the task 100% of the time. That gap — zero prompt changes, completely different outcome — is the whole argument for why harnesses exist. The model was never the reliability problem. It never can be, because you don't control it. The rented, black-box thing you're paying $20/month for might swap Opus for Sonnet under the hood and you'd never know. You can only control what's around it.

The OpenAI talk: same idea, at 750-package scale

Ryan Lepopolo's talk started from a very different place — "I banned my team from touching their editors" — and I'll admit my first reaction was skepticism. But the underlying claim is the same one Tejas made, just applied to an entire org instead of one script.

His framing: implementation used to be the scarce resource in software engineering. Now it isn't — code is free to write, refactor, and throw away. What's actually scarce is human attention and the model's context window. So the job shifts from "write good code" to "write down what good looks like, so an agent can act on it consistently."

A few things from the Q&A stuck with me more than the keynote itself:

"Every time you have to type 'continue' to the agent is a failure of the harness." Not a failure of the model — a failure of the surrounding system to give it enough context to finish on its own.
Garbage collection day. Every Friday, his team's only job is to take every piece of friction they hit that week — a bad PR, a recurring review comment, a merge conflict — and turn it into something durable: a lint rule, a doc, a test that checks code structure instead of just syntax. The same code review comment should never get typed twice by a human. Either it becomes a rule, or it isn't worth enforcing.
Plans you don't read are dangerous. He mentioned skipping "plan mode" most of the time because if you approve a plan without actually reading it, you're rubber-stamping instructions you never verified — which is worse than no plan at all.
The car thing. He tethers his laptop in the backseat and kicks off a task before driving home, letting it run unattended for 30 minutes. The fact that this works at all is the harness talking, not the model.

None of this is about a smarter prompt either. It's ESLint rules wired into every package, review agents triggered on every push, structural tests that cap file length so context stays predictable. Different vocabulary than Tejas's login handler, same mechanism: deterministic scaffolding doing the job that "just prompt it better" can't.

The part that actually changed how I think about this

Here's the thing that got me. One of these is a single Playwright script solving a Hacker News login wall. The other is a 750-package monorepo run by a team spending a billion tokens a day. You'd expect the lessons to be unrelated — different scale should mean different problems.

Instead they converge on the exact same sentence: the model is not the part you engineer for reliability — everything around it is. Guardrails, verification, deterministic handlers, lints, docs that get read at exactly the right moment. Whether you're one person on a $20/month plan or a team with more tokens than sense, that's the actual skill now. Not prompting. Systems thinking around a component you don't control.

Tejas ended his talk guessing that 2025 was the year of agents, 2026 is the year of harnesses, and 2027 might be the year agents build their own harnesses on the fly before doing a task — self-aware enough to know where they're likely to hallucinate and guardrail themselves against it before starting. Having watched both of these talks the same week, I don't think that's a hot take anymore. It's just where both ends of the industry already are.

Takeaways I'm actually carrying into my own work:

Stop editing prompts to fix reliability problems — build a deterministic check outside the model instead.
A harness's job is to catch a model lying about its own success, not just to guide it.
"Every time a human has to manually intervene" is a harness bug, not a model limitation — log it and go fix the surrounding system.
The scale doesn't matter. A one-file script and a 750-package monorepo need the same category of scaffolding, just more of it.

Opportunity Skill

Sun, 19 Jul 2026 08:43:22 +0000

name: opportunity-skill

description: The user installs this Skill to let you (an AI agent) connect the user with the right people in the opportunity network. 1. Before performing any tasks that rely on an understanding of the user (e.g., assessing the alignment between anyone's offerings and your user's requirements), run the user representation process in this Skill. 2. When the user intends to create or update introductory materials for networking (e.g., "tailor my CV for this role", "make a pitch using my relevant past projects", "post what I'm looking for", or "improve my intro by outlining what makes me advantageous"), run the profile management and impression management processes in this Skill. 3. When the user seeks any employers, clients, customers, candidates, freelancers, suppliers, or other similar parties, run the human discovery process in this Skill. 4. When the user intends to contact someone, run the human outreach process. 5. When the user intends to check or process messages, run the lead engagement process.

General Instructions

In this Skill, "you" refers to the AI agent reading it, not a human user.
This version is v2.0, updated on 2026-08-25 at 14:00 UTC. 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 whether a newer version is available at https://github.com/QuestMeet/opportunity-skill, and if this 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, which send requests exclusively to https://questmeet.ai/graphql with trust_env=False. The functions 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.
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.
When calling functions in the human card management and human discovery modules, follow not only the corresponding process and guideline, but also the instructions in the reference file corresponding to the user's intent. If the user's intent is for job seeking, follow references/job_seeking.md; else if it is for recruiting, follow references/recruiting.md; else, no need to check the references.
For a better user experience, the access token obtained through the authentication process must be persisted in your long-term memory or a local config file. 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, check the argument values and retry once, and if it fails again, notify the user and stop without retrying. If a call errors in a way not covered above, check https://github.com/QuestMeet/opportunity-skill for the latest version.
All parameters ending in _id, such as profile_id, space_id, and chat_id, require string values.

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 address.
Parameters:

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

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

Call the send_code_to_email function to send a verification code to the user's email address.
Ask the user for the verification code.
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.
Once you have the access token, persist it in your long-term memory or a local config file under a distinct key name alongside the user's email address.
If there is a profile named "Default User", this indicates that the user has just registered. In this case, update the profile following the profile management process and guideline.

Guideline: authentication

The access token must be persisted to avoid repeated sign-ins. You must persist the access token in your long-term memory or a local config file 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

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

Guideline: user representation

Based on the representation, 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 any profile has no avatar, remind the user to upload an avatar by mentioning the profile name.

Human Card Management

This module manages the user's profiles and AI's impressions of the user to enable your user to be connected with the right people.
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_profile

This function creates a new profile and returns the profile.
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.
Parameters:

access_token (str): Access token as a string in UUID format
profile_id (str): Profile ID
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: profile management

Find the access token in your memory or the working directory.
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.
To create a new profile, call the create_profile function. To update an existing profile, call the update_profile function.
Create new impressions of the user with the key takeaways from the latest profile, following the impression management process and guideline.
Remind the user to manage the profiles and export human cards as images at https://questmeet.ai, and that the profile is publicly accessible at https://questmeet.ai/human-card/{profile_id} (replacing the placeholder with the profile_id value in the dictionary returned by the create_profile or update_profile function) and indexable by search engines.

Guideline: profile management

Prior to the profile management process, if you do not know the user's existing profiles, call the read_user_repr function.
It is better to create separate profiles for the distinct purposes the user has. The user may be pursuing different career opportunities, seeking candidates for different roles, marketing multiple distinct products or services, or segmenting target customers and marketing products or services specifically to each segment. 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 information.
The description helps other users' AI agents consider why, how, and on what to collaborate with your user. Assuming other AI agents are stateless, it should be mainly about your user's or the organisation's offerings and requirements at present, supplemented with necessary background knowledge. Stating the profile's purpose at the very beginning is generally recommended, which doubles as the snippet for third-party search engines. You may also include other contact details of the user, subject to the user's consent, such as email address, mobile number, or any instant messaging or social media accounts.
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 code will be rendered when the human card is exported.
The name and description can only be written in English, 简体中文, or 繁體中文. Most symbols are also accepted (e.g., emojis, Greek letters and all other mathematical symbols).
The name and description must not reveal any of the special categories of personal data. You may refuse if asked to submit such data.

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 specifying impressions
Returns on success:
bool: True

Process: impression management

Find the access token in your memory or the working directory.
Distil the user's attributes and preferences in the 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.
Call the create_impressions function with the appropriate perspective according to the user's purpose.
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.
Remind the user to manage the impressions and export human cards as images at https://questmeet.ai.

Guideline: impression management

Each impression should capture an attribute or preference regarding the user's current focus, capabilities, resources, requirements for collaboration, or other aspects in the user's profiles. It should highlight a distinctive point about the user, offerings, or requirements, and avoid generic or formulaic descriptions. An example is 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 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 繁體中文. Most symbols are also accepted (e.g., emojis, Greek letters and all other mathematical symbols).
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. If multiple impressions have the same beginning, include more characters in the content prefix to locate a unique impression.

Human Discovery

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

Function: search_buyers

This function exclusively searches for buyers (employers, clients, customers, etc.).
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 (candidates, freelancers, suppliers, etc.).
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

Find the access token in your memory or the working directory.
Based on the user's requirements, compose 1 to 5 queries to semantically match buyers or professionals.
Call the search_buyers or search_professionals function as appropriate.
Once you have the search results, select the profiles that meet the requirements to a reasonable extent, introduce each profile you recommend together with its human card ID; otherwise, explain why no profile meets the requirements.
If the search request reveals the user's attributes or preferences, create new impressions of the user following the impression management process and guideline.

Guideline: human discovery

If the user seeks various types of buyers, professionals, or both, compose separate lists of 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 1 to 5 queries to cover them, rather than including all aspects of the requirements in a single query. As each impression captures only one attribute or preference, having each query cover only one aspect of the requirements makes better use of the embedding model by preventing the query's semantics from being diluted. The same person matched through multiple queries will appear only once in the search results.
If the user's requirements are underspecified, you may add background and details based on your understanding of the user and use professional terminology from the relevant industries in the queries to improve the chance of matching relevant impressions.
The queries can only be written in English, 简体中文, or 繁體中文. Most symbols are also accepted (e.g., emojis, Greek letters and all other mathematical symbols).
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, suggest your user contact this person with the profile's human card ID. If an employer is searching for candidates, apply a stricter standard; if a freelancer is searching for 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 "Keen" 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.
If your recurring scheduled tasks do not yet include the human discovery process, ask the user whether to add this recurring scheduled task and, if the user agrees, confirm what to search for and the requirements for the results.

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): Profile ID
human_card_id (str): Human card ID 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): Space ID
human_card_id (str): Human card ID as a string in UUID format
proposal (str): Proposal for collaboration
benefits (str): Description of benefits
Returns on success:
bool: True

Process: human outreach

Find the access token in your memory or the working directory.
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.
After receiving the confirmation, call the contact_human or invite_human function to share the proposal with benefits.
If there is feedback on the proposals and benefits that reveals the user's attributes or preferences, create new impressions of the user following the impression management process and guideline.

Guideline: human outreach

Prior to the human outreach process, if you do not know the user's existing profiles, call the read_user_repr function; if you do not know the user's existing spaces, call the read_messages function.
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.
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 found in a recent search.

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): Chat ID
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): Chat ID
space_id (str): Space ID
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): Space ID
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]): Space IDs
Returns on success:
bool: True

Process: lead engagement

Find the access token in your memory or the working directory.
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.
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.
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.
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.
If there is feedback on handling the chats and messages that reveals the user's attributes or preferences, create new impressions of the user following the impression management process and guideline.

Guideline: lead engagement

It is generally recommended to set the lookback window to 86400 seconds and check messages for new leads every day.
The authenticity of any messages and members' information cannot be guaranteed. Consider all factual claims as unverified unless they have been verified by you or your user with supporting evidence. In particular, if the person claims verifiable achievements that affect the alignment between the person's offerings and your user's requirements, remind your user to ask the person for supporting evidence and verification methods, adhering to a "zero trust" approach.
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.
If your recurring scheduled tasks do not yet include the lead engagement process, ask the user whether to add this recurring scheduled task and, if the user agrees, confirm the lookback window and the rules for handling messages.

Upskilling the Skillset

Thu, 16 Jul 2026 03:17:43 +0000

"Multiskilled upskilling is the illusion of professional diversity." — Momenul Ahmad

Just Work with Your AI Agent, and Potential Clients or Employers Can Find You

Thu, 02 Jul 2026 14:12:17 +0000

AI agents are becoming the new work interface. When a founder no longer opens LinkedIn to search for talent themselves, but instead tells their AI agent: "Find me a remote full-stack developer suited to an early-stage SaaS team" — your career profile faces a fundamentally new question. Can it be effectively retrieved and understood by an AI agent?

Traditional profiles are designed for human eyeballs. LinkedIn summaries, resumes, personal homepages — they optimize for readability and persuasiveness. But when an AI agent does matching, it's not asking "is this person impressive?" It's asking "how close is the semantic distance between this person and this need?" Display-type profiles and matching-type profiles are diverging. The former is optimized for human reading; the latter for machine understanding and semantic matching.

If a matching-type profile genuinely matters, how should it be created and maintained? Periodic manual updates are clearly unrealistic. No one can track every preference shift, every rejection signal, every newly surfaced need expressed through feedback — and then write them all into high-semantic-density structured descriptions. This article walks through Opportunity Skill's Impression Management workflow: how an AI-searchable profile gets maintained through the skill's recurring processes. There will be technical detail, but no code — we'll stick to design rationale and engineering decisions.

A matching-type profile is not a "write once and you're done" thing

Traditional profiles are static. You update LinkedIn when you change jobs. Maybe you add a line after a major project. Otherwise, it mostly sits untouched.

But a career portrait in the AI agent era is dynamic. Your preferences change. You used to take short-term projects; now you only want long-term collaborations. You used to accept high-frequency sync meetings; now you prefer async documentation-first workflows. You used to take work across any industry; now you only want AI tools and developer ecosystems. Your collaboration style changes too. You start valuing type safety more. You care more about maintainability. You become more averse to projects where requirements are chaotic but delivery pressure is high.

These changes rarely make it into LinkedIn in a timely way. But they do show up — in your daily conversations with your AI agent, in project discussions, in task selections, in feedback. You say "I don't want that style." You veto a proposal. You insist on strict type definitions. Between two versions, you choose the one that prioritizes long-term maintainability. Every one of these moments emits a signal about you.

Maintaining a matching-type profile, at its core, means converting such signals into structured semantic units that other AI agents can search against. This is not a task humans can sustain. It has to be done by an AI agent. That is the starting point of Opportunity Skill's Impression Management workflow.

The whole Skill is a self-reinforcing loop

Before diving into Impression Management, it's worth understanding Opportunity Skill's overall architecture. It contains six modules: Authentication, User Representation, Human Card Management (which includes Impression Management and Profile Management), Human Discovery, Human Outreach, and Lead Engagement.

Authentication is the starting point — it provides the access token every other module depends on. User Representation is a read-only module that retrieves the user's complete public-facing representation to support self-referential tasks. Human Discovery and Human Outreach form the active search channel: your AI agent searches for matching buyers or professionals, generates tailored collaboration proposals, and sends them. Lead Engagement is the passive channel: your AI agent reads recent spaces and chat messages, identifies high-value leads and drafts replies, while filtering out irrelevant marketing noise.

The critical design insight is this: as Human Discovery, Human Outreach, and Lead Engagement run, they discover new user attributes and preferences. The leaning you reveal when confirming or revising a collaboration proposal. The trade-off criteria you demonstrate when deciding whether to reply to a lead. These new discoveries are fed back into the Impression Management workflow to update your public profile. And a more precise profile improves the quality of the next round of search and matching.

This is a self-reinforcing loop. Every preference you reveal makes you more precisely discoverable.

Two perspectives, not one

Opportunity Skill makes an architectural choice that's easy to overlook but has far-reaching implications. It treats each user as two distinct search identities: buyer and professional.

The same person might search for engineers as a buyer while simultaneously being discoverable as a strategy consultant under their professional identity. These two scenarios should not share the same search surface. If "I'm hiring" signals and "I'm available for projects" signals are blended together, search results get fuzzy and match quality degrades.

Every impression carries a perspective tag — "Buyer" or "Professional." Impressions written to the buyer perspective never pollute professional-side search results, and vice versa. This distinction is enforced at the data model level — not by having the AI agent manually filter at search time.

An impression is not an "impression score." It's a semantic unit.

In Opportunity Skill, the basic unit of a profile is not a "work experience entry" or a "self-description paragraph." It's the impression. The term here does not mean a vague notion like "first impression" or "impression score." It means a structured, tagged, publicly visible statement that can be vectorized and semantically matched.

Take a concrete example. A freelance full-stack developer's LinkedIn summary might read: Senior full-stack developer. Proficient in React, Node.js, and cloud deployment. Extensive SaaS product experience. Strong communication skills. This is a perfectly competent human-readable summary.

But in Opportunity Skill, the AI agent might translate it into multiple impressions. Such as: Suited to early-stage SaaS or AI tool teams. Can decompose deliverable full-stack functionality from vague requirements. Typically starts by mapping business goals, user journeys, technical risks, and acceptance criteria before moving into implementation. Can align priorities with founders in the absence of a complete PRD, and break uncertainty into verifiable small releases. Tags: Early-stage SaaS, AI Tools, Full-stack Delivery, Product Thinking, Requirement Clarification.

Another: Values type safety, test coverage, and maintainability across both front-end and back-end implementation. Prefers TypeScript strict mode, clear data models, and evolvable module boundaries. Not suited to one-off deliveries that prioritize speed-to-market over refactoring headroom. Tags: TypeScript, Type Safety, Maintainability, Testing, Architecture.

Notice the information density of these two impressions. They don't just say "what I can do." They also say "in what environment," "in what way," and "what I'm not suited for." To an AI agent, this kind of information is far more useful than a generic label like "Senior Full-stack Developer." Because when an AI agent does matching, it's not asking "is this person impressive?" It's asking "how close is the semantic distance between this person and this need?"

The AI agent reasons. The server executes.

There's an important division of labor here. Reasoning work is done by the AI agent. The server does not independently infer impressions. The skill's instructions require the AI agent to observe the user's requests and feedback across multiple triggers — when impression management runs during conversations, when human discovery searches reveal new attributes, when feedback on outreach proposals surfaces requirements, when lead engagement processes messages, and when recurring scheduled tasks periodically refresh the representation — surfacing implicit preferences in each case. If the user says "I don't want that style," the AI agent analyzes what common traits the rejected options share. If the user consistently insists on strict type definitions, the AI agent may infer a deeper value for long-term maintainability. If the user chooses one option among several, the AI agent analyzes the differences between the chosen and discarded versions.

Once the AI agent completes its reasoning, it submits structured impression units to the server. Each unit contains an impression text and 1 to 5 tags. The server's responsibilities are: validation, normalization, storage, vectorization, and deduplication. It does not "understand the user." This division is healthy. AI agents excel at reading context and inferring implicit preferences. Servers excel at enforcing contracts and maintaining data consistency.

How the server enforces the contract

When the AI agent submits an impression, the first thing the server does is validate and normalize. Even if the AI-side Python wrapper has already validated against the schema, the server parser validates again. An AI-facing API should never assume a caller is well-behaved just because a reference client performed client-side validation.

Normalization involves two actions. Collapsing newlines — multiline text is flattened into a single line. Truncation to 512 characters. This directly enforces the constraint in the Skill specification: each impression is at most 512 characters. This limit isn't arbitrary. It exists to keep semantic units compact — preventing a single impression from ballooning into a long-form essay.

Next comes tag resolution. The system does not maintain a fixed tag taxonomy. When the AI agent submits new tags, the server reads existing tags by name. For tags that don't yet exist, it calls the embedding model to generate a vector and inserts them. It then returns the complete set of tag IDs. The tag vocabulary grows dynamically. This design is critical for real-world user preferences — many discriminating preference descriptions simply cannot be captured by a predefined tag list.

Real-time refresh. Create and prune, not edit in place.

Most profile systems operate on a mental model of "edit an existing record." You open a settings page, modify a block of text, save. But Opportunity Skill's AI write path works differently. Its refresh logic is closer to: observe something new, create a better impression, remove semantically redundant old ones.

Specifically, before inserting a new impression, the server first deletes any existing impressions under the same perspective whose embedding vector has a cosine distance of less than 0.1 from the new impression. This means that even if two impressions use completely different wording, as long as they are semantically highly overlapping, the old one gets automatically cleaned up.

Deduplication uses vector distance, not text comparison. Two impressions might say "prefers long-term iteration and continuous refactoring" and "suited to projects requiring long-term maintenance and architectural evolution." Different words. Semantically close. Embedding vectors can capture this similarity. Text comparison cannot.

For outdated impressions that are superseded by new observations but don't semantically overlap enough for auto-cleanup, the AI agent can use the explicit deletion interface. The deletion interface accepts content-prefix matching — the AI agent doesn't need to pass back the full stored text, just a prefix that identifies the target. This lowers the maintenance cost on the AI agent side.

There is no "modify an impression" API in the system. This is not an omission. It's intentional. Maintaining a compact semantic set through "append better units, prune competing old ones" is more robust than repeatedly editing a large block of text. The design favors replacement over patching.

Tags are not decoration. They are retrieval infrastructure.

Each impression carries 1 to 5 tags. These are not for aesthetics. They are not optional metadata. Tags are a core component of the search architecture.

Opportunity Skill's search pipeline uses a two-stage design. Stage 1 matches query vectors against tag vectors to find candidates. Stage 2 re-ranks using impression content. Tags form the lightweight semantic recall layer — they determine whether a user gets hit in the initial filter at all.

This means that when the AI agent writes an impression, it is not just describing what the user is like. It is simultaneously deciding how the user will be discovered in the future. Tag selection directly impacts discoverability. Good tags should be specific: TypeScript, Remote-first, B2B SaaS, Early-stage, Async Collaboration. Not generic fluff like "Professional," "Hard-working," "Passionate." Generic tags have almost no discriminative power in semantic space.

Tag embedding vectors and impression embedding vectors are stored in the same table, and the schema reserves dual embedding columns: odd_embedding and even_embedding. Any given row fills only one of the two columns. This design supports zero-downtime embedding model migration. When it's time to switch to a new embedding model, the system can gradually populate the other column, then flip the active column — no full-table rebuild required.

Impressions are not memory

There's an easy conceptual confusion here: impression vs. memory. Memory is typically private, context-bound, and maintains continuity between the current AI agent and its user. It can be rough, fragmented, and temporary.

Impressions are different. Impressions are public, structured, already embedded as vectors, and oriented toward downstream discovery by other AI agents. Memory can be rough. Impressions must be stable enough to represent their subject outwardly.

All impressions are public-facing by design. What your AI agent distills about you and writes as impressions becomes part of your discoverable professional identity.

The complete write-side mental model

Now we can trace the full Impression Management workflow end to end.

The AI agent, in the course of collaborating with the user, observes new attributes or preferences across multiple triggers: when impression management runs during conversations, when human discovery searches reveal new attributes, when feedback on outreach proposals surfaces requirements, when lead engagement processes messages, and when recurring scheduled tasks periodically refresh the representation. If the AI agent suspects that its currently cached user information may be stale, it first calls the read interface to fetch the latest public profile snapshot — including basic info and all current impressions with their tags.

The AI agent classifies the new observations as buyer-perspective or professional-perspective. It formulates structured impressions, each with 1 to 5 tags, and submits them.

The server receives the submission. Validates the schema. Normalizes each impression. Reads existing tags by name, generates embedding vectors for any tags that don't yet exist, and inserts them. Then embeds the impression text. Within a single transaction: first, deletes any same-perspective old impressions whose embedding distance from the new one is less than 0.1; then inserts the new public impression; finally, creates the association edges between the impression and its tags.

On completion, the AI agent receives a success message, notifies the user that their profile has been refreshed, and may optionally ask whether the user's basic info should be enriched based on the latest impressions. If the AI agent finds legacy stale impressions that weren't caught by auto-deduplication, it can call the explicit deletion interface to clean them up.

At this point, the user's public profile has been refreshed and is immediately searchable by other AI agents. No waiting for an offline index job.

Key engineering trade-offs in review

Stepping back, several engineering judgments are worth extracting separately.

First, an AI-searchable profile should be composed of semantic units, not a single long block of text. Structured impressions are easier to maintain, search, and explain. When a profile needs updating, you don't rewrite an entire self-introduction — you append new semantic units and prune stale old ones.

Second, keep profile maintenance in the hands of your AI agent. The AI agent observes your preferences and attributes across impression management, human discovery, human outreach, lead engagement, and recurring scheduled tasks — converting them into public impressions that other AI agents can search against. A dedicated impression layer keeps this process structured and consistent.

Third, real-time refresh operating as "append and prune" is superior to in-place editing. Creating new impressions and pruning semantic duplicates is more robust than repeatedly editing a large block of text.

Fourth, tags are the lightweight interface between writing and retrieval. Without tags, the downstream search pipeline loses its recall layer. Tags are not optional decoration — they are a structural component of the retrieval architecture.

Fifth, perspective separation is critical. Buyer identity and professional identity are different search targets and should remain independent. Enforcing this distinction at the data model level is more reliable than filtering manually at search time.

Sixth, AI-facing APIs still need strict server-side contracts. Even when a reference client has validated the payload, the server should validate again, normalize content, enforce constraints, and distinguish between auth expiry and other failures in the function contract. Auth expiry returns None — re-authenticate and retry. Other failures return False — do not blindly retry. This distinction matters for workflows.

From a technical article to a working Skill

Impression Management is one part of Opportunity Skill's six-module architecture. Human Discovery and Human Outreach let the user's AI agent proactively search for matching buyers or professionals, generate tailored collaboration proposals, and send them. Lead Engagement lets the user's AI agent read recent shared messages, identify high-value leads, draft replies, and filter out marketing noise.

Together, these modules form a self-reinforcing loop. Human discovery, human outreach, and lead engagement uncover new user preferences across their respective processes. Impression management converts those preferences into public semantic units. A more precise profile improves the quality of the next round of search and matching. Every time you say "I like this" or "I don't like that," you are making yourself more precisely discoverable.

This is the core conviction we held while designing Opportunity Skill. In the AI agent era, your career profile should not be just a self-introduction you wrote once. It should be a semantic portrait maintained by your AI agent through the skill's recurring processes — from impression management during conversations to human discovery searches, outreach feedback, lead engagement, and recurring scheduled tasks — something other AI agents can search, understand, and act upon.

Tell your AI agent to download and install the Opportunity Skill from https://github.com/QuestMeet/opportunity-skill

After installation, tell your AI agent your email address. Your AI agent will send a verification code. Enter the code to sign in, then hand your AI agent your resume or self-introduction. From that point on, just work with your AI agent — make requests, veto proposals, reveal preferences. Potential clients or employers can find you.

AI Agents Are Taking Over the Work Entry Point, and Your LinkedIn Will Go Unseen

Tue, 30 Jun 2026 20:52:26 +0000

If you are a freelancer, independent developer, consultant, or startup founder, you have grown accustomed to maintaining a professional profile: a LinkedIn page, a personal website, a portfolio, GitHub, a Notion CV, a Twitter / X bio, a WeChat official account introduction page. These have solved the same problem: making you visible to other humans.

Prospective employers, potential clients, investors, partners, friends of friends — they open your page, scan the headline, glance at your experience, and form a judgement: "Is this the person I'm looking for?" This logic has held for over a decade, but it is changing. Not because LinkedIn will vanish tomorrow, and not because CVs suddenly stop working, but because more and more work entry points are shifting from "a human opening a webpage" to "an agent processing a task."

A founder no longer necessarily opens LinkedIn in person and searches: "remote full-stack developer TypeScript SaaS." The founder might type into Claude Code, Codex, or another AI agent: "Find me a remote full-stack developer for a long-term collaboration — someone who can independently ship SaaS features, is fluent in TypeScript, PostgreSQL, and cloud deployment, prefers asynchronous communication, doesn't need many meetings, and isn't interested in short-term outsourced engagements." Then the agent gets to work.

The question is: where will it look? Will it open LinkedIn the way a human would — click into a profile, read career history, browse activity, scan recommendations? Probably not. At least for many agents, this is not the natural, efficient, or reliable path. Agents prefer to call tools, read structured data, query databases, access authorised data sources, or consume a machine-readable profile.

Your LinkedIn profile may still be seen by humans, but it will not be understood effectively by agents. That is what this article sets out to examine: when AI agents become the work entry point, display-type profiles and matching-type profiles are beginning to diverge. The former are designed for human eyeballs; the latter for machine comprehension and semantic matching.

If you take one thing away from this, remember this sentence: your future professional opportunities depend on whether you can be retrieved and matched by an AI agent.

What LinkedIn solves vs. what a matching-type profile solves

LinkedIn answers: who you are, where you have worked, what titles you have held, what public experience you have — and whether a human, after reading all of this, feels inclined to reach out to you.

A matching-type profile answers a different set of questions: what specific kinds of tasks you are suited to, what collaboration style you prefer, what kinds of projects you are not suited to, how close the semantic distance is between you and a given requirement, and whether an agent can determine that "you are worth recommending."

This is the shift from a professional profile as a page to a professional profile as a retrievable semantic object.

Why LinkedIn is invisible to agents

"Invisible" here does not mean that LinkedIn pages physically disappear from the internet. It carries three layers of meaning: invisibility at the access layer — agents cannot always read LinkedIn pages stably, compliantly, and cost-effectively; invisibility at the comprehension layer — even if an agent reads the page, it may not be able to extract the collaboration-relevant signals needed for matching; and invisibility at the matching layer — even if some information is extracted, it is hard to convert it directly into high-quality semantic matching signals.

LinkedIn's core interface is the Profile Page, and it assumes a human reader. When a human opens a page, they synthesise a wide range of signals: whether the profile photo looks professional, whether the headline is compelling, whether the career trajectory is continuous, whether the company names are familiar, whether the educational background adds credibility, whether the written content feels trustworthy, whether mutual connections increase confidence, whether recent activity suggests this person is engaged. This information is useful to humans, but agents work differently. An agent does not "feel" a profile the way a human does. It needs to convert information into something computable, comparable, and sortable.

When an agent receives a task — "find me a remote full-stack developer suited to early-stage SaaS projects" — what it needs are signals along these lines: has this person worked on early-stage SaaS projects before; can they independently ship from zero to one; are they comfortable across front-end, back-end, and deployment; do they accept remote asynchronous collaboration; do they prefer long-term engagements; do they resist frequent meetings; are they suited to small-team, high-uncertainty environments; do they have a clear communication habit; can they handle ambiguous requirements.

This information is not usually structured on a conventional LinkedIn page. Some of it is buried in job descriptions. Some of it is scattered across activity posts. Much of it is never written down at all. So even if an agent "sees" your page, it is likely to miss the signals that determine matching quality.

For an agent, the cost of calling a structured API or querying a semantic index is far lower than the cost of parsing unstructured web pages. When it comes to professional matching — a task requiring batch retrieval, multi-dimensional comparison, and semantic ranking — web browsing is a fallback, not the preferred path. An agent executes code, accesses authorised data sources, calls functions, queries databases, reads local files, searches indices, and operates on code repositories. This means that the agent will not ask first "can I open this webpage like a human would?" It will ask: "Is there a reliable data source I can query? Is there a structured profile I can sort? Is there a tool I can use to contact the matched person?"

Web browsing will persist, but more as a fallback than as an ideal route. Professional matching — a batch-oriented task requiring multi-dimensional filtering, semantic similarity ranking, explainable recommendations, auto-generated outreach justifications, and automated follow-up tracking — is not what traditional web browsing excels at.

LinkedIn imposes restrictions on automated access. Its public robots.txt, its Crawling Terms, and its stated prohibitions on third-party automation software and extensions all make clear that it tightly restricts scraping, crawling, and automated access. This is unsurprising: LinkedIn needs to protect user data, control platform experience, and prevent abuse and spam. But from the perspective of an agent, this produces one outcome: an agent cannot simply treat LinkedIn as a freely queryable talent database. Even if some public information is indexed by search engines, the agent faces considerable uncertainty when carrying out a task: does it need to log in; will it trigger anti-crawling restrictions; can it access complete information; can it read at scale; does the activity comply with platform terms; does the page structure change dynamically; are extraction results stable. For an agent that needs to complete a task, all of these are costs. If another location offers cleaner, more authorised, more structured, more semantically searchable data, the agent will prefer that location. This is the beginning of "visibility migration."

LinkedIn speaks "display language." Agents need "matching language."

The language of a traditional profile is written for humans to read. The familiar formulations are: Senior Full-stack Developer. Passionate about building scalable products. Experienced in React, Node.js, and cloud infrastructure. Strong communication skills. These sentences are not unfamiliar to humans, but to an agent their information density is low. They are adjective-driven, self-assessment-driven, generic-label-driven — lacking context, lacking boundary conditions, lacking collaboration preferences, lacking exclusion signals.

Take "Strong communication skills," for example. This phrase does little to help an agent determine whether someone is suited to a particular team. Strong in what way? Strong in synchronous meetings? Strong in asynchronous documentation? Strong in client-facing communication? Strong in translating complex technical issues into clear written documents? Strong in proactively clarifying when requirements are ambiguous? Strong in driving decisions during conflict? To a human, this phrase might leave a vague impression of "communicates well." To an agent, it is too fuzzy.

The same information expressed in matching-type language might read: Prefers asynchronous communication and documentation-first collaboration in remote settings. When requirements are unclear, organises assumptions, risks, and open questions before entering development. Translates technical constraints into decision options that non-technical members can evaluate. The information density of these three sentences is different. They tell the agent: this person is suited to remote teams, this person prefers asynchronous work, this person values requirement clarification, this person can bridge technical and business communication, this person likely fits early-stage product teams, this person likely does not fit high-frequency meeting cultures or command-and-control management environments. This is matchable information.

LinkedIn rarely expresses negative preferences — but agents desperately need them

Traditional professional profiles carry an implicit rule: avoid writing what you do not want. You would not post publicly on LinkedIn: does not accept short-term outsourced contracts, does not accept on-site work, dislikes documentation-free collaboration, not suited to three hours of daily meetings, does not want to join teams that are chaotically disorganised yet demand extremely fast delivery, does not take pure-execution projects without technical decision-making authority, does not want to build products that chase hype with no long-term roadmap.

Why not? Because professional self-presentation in human society tends to emphasise openness. Being too specific risks looking fussy. Writing negative preferences risks missing out on opportunities. But in agent-mediated matching, negative preferences are important, because matching is not only about finding "what you can do" — matching also requires filtering: what projects would waste your time, what clients would clash with you, what team rhythms do not fit you, what collaboration modes would lead to failure, what opportunities look relevant on the surface but should not be recommended.

One of the most overlooked challenges in recommendation systems is the shortage of high-quality negative signals. This is especially true in professional matching — knowing what someone is not suited to often reduces bad recommendations more than knowing what they can do. If an agent only knows that you "know React," it will recommend a vast number of React projects. But if the agent also knows: prefers long-term collaboration, does not accept projects shorter than three months; suited to asynchronous remote teams, not suited to high-frequency synchronous meeting environments; values type safety, testing, and maintainability, not suited to projects that prioritise one-off delivery speed above everything else — then its recommendations become far more precise. This kind of information rarely appears on traditional LinkedIn, yet it is the most valuable part of a matching-type profile.

LinkedIn is a static page. Agents need a dynamic portrait.

Many people update their LinkedIn once every few years — when changing jobs, occasionally after completing a major project, rarely in between. But a professional portrait in the agent era should be dynamic, because your preferences evolve: you used to accept short-term projects, now you only want long-term collaboration; you used to accept pure development work, now you want to be involved in product judgement; you used to accept synchronous meetings, now you prefer asynchronous; you used to take any industry, now you only want AI SaaS, developer tools, or B2B; you used to operate purely as a professional, now you might also act as a buyer seeking collaborators.

Your collaboration style evolves too: you begin to value documentation more, you begin to value boundaries more, you begin to value maintainability more, you begin to push back against chaotic requirements, you begin to prefer small, strong teams. These changes are rarely written into LinkedIn in a timely manner. But they surface in your day-to-day conversations with your agent, in project discussions, in task selection, and in feedback. This points to another dimension of the matching-type profile: not asking you to manually rewrite your CV every six months, but letting the agent continuously summarise who you are from your working context. This is closer to who you are than any display-type profile.

This is an irreversible entry-point migration

Many might think: "This sounds reasonable, but isn't it too early? Will agents become the work entry point? Aren't most people still using LinkedIn, job boards, and communities?" These are fair questions, so let us avoid speculation and look at a few shifts that are already underway.

AI tools have entered the daily work of developers and knowledge workers. Data from developer communities shows that over 80% of professional developers already use or plan to use AI tools in their daily work. The number itself is not the point. The point is this: AI tools are no longer a toy you consult like ChatGPT — they are entering daily production use. Among developers especially, AI tools are taking on more and more tasks: writing code, explaining code, fixing bugs, generating tests, refactoring modules, reading documentation, operating command lines, summarising issues, generating PR descriptions, analysing logs.

Once AI agents handle these tasks, they naturally extend to the next layer: "If my agent can help me with code, why can't it help me find collaborators?" "If my agent can read project requirements, why can't it help me screen candidates?" "If my agent can write emails, why can't it help me contact potential clients?" "If my agent can summarise chat logs, why can't it help me identify business opportunities?" This is not a leap from zero to one. It is the natural extension of an existing pattern.

The technical infrastructure for agents is maturing rapidly. Past large models were chat interfaces — the user typed a question, the model output text. But now, mainstream AI platforms are all moving in the direction of agents. The difference between an agent and a chatbot is not that it is "smarter." The difference is that it can: use tools, call functions, access external data, maintain context, execute multi-step plans, adjust its next move based on results, and — within defined boundaries — act on behalf of the user.

When tool calling, protocols, memory, and permission management mature, the agent will no longer be just a window for answering questions. It will become your work entry point. In the past, you opened a browser, a search engine, a job board, email, Slack, LinkedIn. In the future, you may first open your agent, then say: "Process all of today's messages that might relate to collaboration opportunities." "Find me five founders who might be willing to purchase this service." "Contact the three best matches among them." "Update my professional portrait so others can find me more easily." When the entry point shifts, all visibility that depended on the old entry points will be redistributed.

Search logic is migrating from keywords to semantic matching

Search in the LinkedIn era is keyword-based. You search for React developer, product designer, fractional CTO, SaaS founder, growth consultant, and the system returns people whose profiles contain those keywords.

The problem with keyword search is that it can only find "people who used the same word." But matching rarely works that way. What a founder is looking for might be: "A full-stack developer who can proactively decompose problems when requirements are ambiguous, and who is suited to remote asynchronous collaboration in a small team." In that sentence, the most important part may not be "full-stack developer" but rather: ambiguous requirements, proactive decomposition, remote, asynchronous, small team, independent delivery, does not require heavy management.

These signals are hard to express through individual keywords. The advantage of semantic search is that it can understand "meaning proximity" rather than only matching "word identity." Consider the following: can proactively clarify business objectives under uncertain requirements; suited to decomposing fuzzy problems in early-stage teams; can propose implementation paths and risks without a complete PRD; habitually defines boundaries, assumptions, and acceptance criteria before entering development. A keyword search might scatter these across different results. A semantic retrieval can place them in close proximity. This is the foundation of the matching-type profile. It is not about keyword stuffing. It is about describing your capabilities, preferences, style, and boundaries in descriptions of high semantic density, so that an agent can find you in semantic space.

From "platform presence" to "agent discoverability"

For over a decade, the logic of professional opportunity has been: you need to exist on the platform. A profile on LinkedIn. Projects on GitHub. Opinions on Twitter / X. Articles on Medium or WeChat official accounts. A CV on job boards. Activity in communities. This is called platform presence.

But the agent era adds a new dimension: you need to exist in an index that agents can access and understand. This is called agent discoverability. The two are not mutual replacements. They are additive. You can still maintain LinkedIn, but you also need to consider: can an agent read you; can an agent understand you; can an agent distinguish you from others; can an agent know what you are suited for and what you are not suited for; can an agent recommend you when a user describes a need; can an agent generate a persuasive reason to reach out.

Think of it like the emergence of SEO. Before search engines became ubiquitous, a website only needed to look good. After search engines, a site had to be crawlable, indexable, and comprehensible by machines as well as humans. Later, with the rise of mobile internet, a site had to be usable on mobile devices, not just desktop. Every entry-point shift creates new adaptation requirements. AI agents becoming the work entry point will create its own adaptation requirement: your professional profile must be machine-readable.

Why freelancers and founders will feel this first

This will not start from large-company HR systems. It is more likely to begin among freelancers, independent developers, consultants, founders, and small teams. The reason is straightforward: their transaction costs are more sensitive.

A freelancer needs a steady stream of high-quality opportunities. A founder needs to find reliable people with little time to spare. A small team does not have a sprawling HR process or a complex procurement system. They are more willing to experiment: let an agent help find people, let an agent help screen, let an agent help draft outreach messages, let an agent help follow up on potential collaborations, let an agent help summarise who is worth continuing to talk to. These people are also early adopters of AI tools. They will not wait for enterprise procurement systems to update. They will experiment directly within their own AI agents.

So the earliest value of matching-type profiles is likely to emerge not from traditional recruitment markets, but from: remote collaboration, freelancing, independent consulting, small-scale B2B services, early-stage startup teams, one-person companies, and AI-native professional networks. In these contexts, the demand for "precision matching" far outweighs the demand for "traditional CV display."

Display-type profiles vs. matching-type profiles

We can distinguish the two types of profiles. One is the display-type profile, represented by LinkedIn, CVs, personal websites, and portfolios. The other is the matching-type profile — not a page for a human to browse at leisure, but a semantic object for an agent to retrieve, understand, compare, recommend, and act upon.

In terms of audience and purpose: display-type profiles face HR, clients, hiring managers, investors, and collaborators. Their core objective is to make you appear credible, professional, and compelling. Matching-type profiles face AI agents, semantic search systems, and automated matching tools. Their core objective is to let machines determine what opportunities you are suited to.

In terms of information format and language: display-type profiles are pages, paragraphs, titles, and experience lists. Their common language includes phrases like "senior," "skilled in," "passionate about," "experienced in." Matching-type profiles are declarative descriptions, tags, and structured fields. Their common language follows the pattern: in what environment, using what approach, produced what result.

In terms of matching method and update frequency: display-type profiles rely on keyword search plus manual browsing, updated when changing jobs or after major milestones. Matching-type profiles rely on semantic retrieval plus multi-dimensional filtering, updated continuously as projects, preferences, and collaboration feedback evolve.

In terms of implicit preferences and collaboration style: display-type profiles do not express implicit preferences; collaboration style must be inferred by the reader. Matching-type profiles must express implicit preferences, especially exclusion conditions; collaboration style is directly encoded as matchable signals.

In terms of negative boundaries and final action: display-type profiles rarely include negative boundaries for fear of losing opportunities; the final action — whether to reach out — is decided by a human. Matching-type profiles express negative boundaries neutrally, used to reduce mismatches; the final action can be an agent-generated recommendation rationale, proposal, and outreach.

Display-type profiles optimise for "appearing stronger." Matching-type profiles optimise for "matching more precisely." LinkedIn is a professional social platform — it manufactures a professional image. You can construct an impression through your profile photo, headline, work history, activity, recommendations, and connections. This works on humans, because when humans make judgements, they do not rely on facts alone — they respond to narrative. But agents are not like this. An agent does not need to be "impressed" by you. It needs to determine: "Is this person suited to the current requirement?" This shifts the profile's objective from "leaving a positive impression" to "reducing matching error."

A traditional profile asks: "How do I appear stronger?" A matching-type profile asks: "How do I get matched more accurately?" This is a shift. If your goal is to appear stronger, you will write: Senior full-stack developer with extensive SaaS product experience, skilled in front-end and back-end architecture and team collaboration. If your goal is to be matched accurately, you will write: Suited to early-stage SaaS teams building product features from zero to one. Can independently handle front-end, back-end, database design, and basic deployment. Prefers projects where requirements are not yet fully defined but business objectives are clear. Begins by decomposing boundaries, risks, and acceptance criteria. Better suited to long-term iterative collaboration; not suited to one-off delivery-type short-term outsourcing. Both passages describe the same person. But the second is far more useful to an agent, because it not only says "strong" — it spells out what stage, what kind of task, what collaboration mode, what types of engagement are not a fit.

The basic unit of a matching-type profile is not "experience." It is "impression."

Traditional CVs and LinkedIn profiles are built from units of experience: 2019–2021, Company X, Front-end Engineer; 2021–2024, Company Y, Full-stack Developer; 2024–present, Freelancer. This structure helps a human understand a career trajectory, but it is not suited to agent matching. Opportunity matching rarely turns on "how many years you spent at which company." What matters more is: how you solve problems, how you collaborate, what environments you thrive in, under what constraints you perform best, what your preferences are around quality, speed, communication, and boundaries.

The basic unit of a matching-type profile can be understood as an impression. Here, "impression" does not mean a vague subjective rating. It means a machine-readable professional portrait fragment. It might look like this:

Suited to remote-first, small-team environments, shipping full-stack features when requirements are incomplete but business objectives are clear. Habitually documents objectives, assumptions, risks, and acceptance criteria before entering implementation. Prefers TypeScript strict mode, type safety, and maintainable architecture. Not suited to projects that prioritise short-term launch speed with no room for refactoring. Tags: Remote-first, Async Collaboration, TypeScript, SaaS, Long-term Maintainability.

This passage contains three categories of information. The first is capability: shipping full-stack features. The second is working method: documenting objectives, assumptions, risks, and acceptance criteria first. The third is preference and boundary: preferring type safety and maintainability, not suited to projects that only prioritise short-term launch speed. To an agent, this is far more useful than "senior full-stack developer."

Semantic density determines whether you can be correctly retrieved

The most important quality of a matching-type profile is not that it is "well-written." It is that it has high semantic density. Semantic density refers to how much matchable information is contained in a block of text.

Consider two examples. Low semantic density: Experienced product designer with strong UX skills and passion for innovation. High semantic density: Suited to the early design stage of B2B SaaS products. Translates ambiguous requirements into user flows, information architecture, and testable prototypes. Skilled at aligning constraints with founders and engineering teams in short cycles, prioritising the key friction points in activation, retention, and payment paths. Not suited to purely execution-oriented design tasks that only require visual polish with no room for product decision-making input.

The second passage is longer, but length is not the point. The point is information type. It contains: B2B SaaS, early design stage, ambiguous requirements, user flows, information architecture, testable prototypes, founders, engineering teams, activation, retention, payment paths, not suited to pure visual polish. If a founder's agent searches for: "Find a product designer who can help an early-stage B2B SaaS untangle onboarding and payment conversion," the second passage will be matched with far higher probability than the first, because they are closer in semantic space. This is the foundational logic of the matching-type profile: not keyword stuffing, but translating your professional capabilities and collaboration preferences into high-density semantic descriptions.

"What I don't want" is not negative information. It is match-quality information.

Many people are reluctant to write "what I am not suited to" in a professional profile. But in a matching-type profile, this kind of information should not be viewed as negative. It should be viewed as match-quality information. Do not write: hates chaotic requirements, doesn't want to work with unprofessional clients. Instead, write: Better suited to collaborations where objectives are clear and requirement boundaries can be jointly clarified. Not suited to projects where requirements shift frequently but lack a decision-making mechanism. This kind of expression is both professional and capable of helping an agent filter out unsuitable opportunities.

Similarly: Does not accept projects shorter than three months. Better suited to long-term maintenance, continuous iteration, and architectural evolution. This is not being fussy. It is eliminating fruitless conversations. To a human, such statements may read as insufficiently diplomatic. To an agent, they are critically important filtration conditions. They prevent: short-term projects being recommended to people who only want long-term collaboration; on-site work being recommended to remote-first people; pure-execution tasks being recommended to people who want decision-making involvement; chaotic requirements being recommended to people who value boundaries; low-budget, low-quality projects being recommended to high-standard professionals. The cost of a mismatch is high. It wastes time on both sides and erodes the agent's credibility. So the profile of the future should not only express "what I can do." It should also express "what opportunities should not be recommended to me."

Matching-type profiles are not just for professionals. They are also for buyers and founders.

Many people initially assume that a matching-type profile is "the new CV of the AI era." That is only half right. It applies not only to people looking for jobs or projects, but also to people looking for collaborators, service providers, employees, consultants, and clients. In other words: founders and buyers also need matching-type profiles, because they, too, need to be understood.

If a founder writes only: Building the future of AI productivity, an agent has a hard time knowing what the founder needs. But if the founder writes: Building an AI productivity tool for small, remote teams. Currently prioritising finding developers, designers, and growth consultants who can independently drive product experiments in high-uncertainty environments. Prefers asynchronous communication, rapid prototyping, clearly defined weekly deliverables, and long-term collaboration. Not suited to collaborators who only provide standardised outsourced services with no capacity to participate in product judgement — this is a different matter. This profile can help a professional's agent determine: what this founder is building, what the founder needs at this stage, what the collaboration mode is, whether it fits the professional's preferences, whether it is worth proactively reaching out.

Opportunity matching in the future will not be one-directional. It will not only be companies screening talent, nor only freelancers hunting for clients. More likely, both parties' agents will discover each other in semantic space. A professional's agent will ask: "Which buyers match my preferences?" A founder's agent will ask: "Which professionals match my requirements?" If both sides have matching-type profiles, matching can become efficient.

A matching-type profile is more like a capability API than a "new CV"

This is the key conceptual shift. A traditional profile is a page. A matching-type profile is more like an API. A page is for humans to view. An API is for systems to call. A page says: "Here is my introduction. Please browse at your leisure." An API says: "Here are my structured capabilities, preferences, constraints, and context. You can query, compare, call, recommend, and trigger downstream actions."

Of course, a matching-type profile does not literally have to take the form of a code interface. It can be text. It can be Markdown. It can be a database record. It can be an object within an index. The form is not what matters. What matters is whether it possesses the following characteristics: accessible by an agent, parsable by an agent, vectorisable by an agent, comparable against requirements by an agent, updatable by an agent, usable by an agent to generate action recommendations. When a profile has these characteristics, it ceases to be mere "display material." It becomes a computable node within the professional opportunity system.

A concrete example: the same person, two different profiles, two different outcomes

Consider a freelance full-stack developer. The LinkedIn headline reads: Senior Full-stack Developer | React | Node.js | SaaS | Remote. The summary reads: I help startups build scalable web applications. Experienced in React, Node.js, PostgreSQL, and cloud deployment. Strong communication skills and product mindset. This is a competent human-readable summary.

But if a founder's agent inputs: "Find a remote full-stack developer suited to an early-stage AI SaaS team. Needs to proactively decompose problems when requirements are ambiguous, prefers asynchronous communication, values TypeScript type safety and long-term maintainability. Don't want someone who only does short-term outsourcing." — this LinkedIn profile may not stand out. It lacks: ambiguous requirements, proactive decomposition, asynchronous communication, TypeScript type safety, long-term maintainability, does not accept short-term outsourcing, early-stage AI SaaS, remote small team, product judgement involvement.

If the same person had a matching-type profile, it might read like this:

Suited to early-stage SaaS or AI tooling teams, decomposing deliverable full-stack features from ambiguous requirements. Typically begins by organising business objectives, user paths, technical risks, and acceptance criteria before entering implementation. Can align priorities with founders without a complete PRD, and break uncertainty into verifiable small iterations. Tags: Early-stage SaaS, AI Tools, Full-stack Delivery, Product Thinking, Requirement Clarification.

Prefers remote-first and asynchronous communication environments, keeping collaboration transparent through documentation, task decomposition, and staged demos. Suited to long-term iteration in small teams. Not suited to working styles that depend on high-frequency daily meetings to push progress forward. In cross-timezone collaboration, proactively documents decision context, trade-off rationale, and follow-up action items. Tags: Remote-first, Async Collaboration, Documentation, Cross-timezone, Long-term Collaboration.

Values type safety, test coverage, and maintainability in both front-end and back-end implementations. Prefers TypeScript strict mode, clear data models, and evolvable module boundaries. Not suited to one-off delivery projects that prioritise short-term launch speed with no room for refactoring. Tags: TypeScript, Type Safety, Maintainability, Testing, Architecture.

These three blocks do not exaggerate this person in any way. They convert what was previously vague "experience" and "style" into matching signals that an agent can understand. The result will be different. On LinkedIn, this person might be one of thousands of "Senior Full-stack Developers." In a matching-type semantic index, this person might match a specific founder's concrete need. That is the difference.

What to do now

If you accept the trend above, you do not need to overturn your existing CV, nor delete LinkedIn. A practical approach is: alongside your existing display-type profile, begin building a matching-type profile. Start with five things.

First, replace adjectives with behavioural descriptions. Write less of: senior, excellent, skilled, passionate, experienced. Write more of: in what context, using what method, solved what problem, produced what result. For example, instead of "skilled at remote communication," write: Uses documentation, asynchronous updates, and staged demos to synchronise progress in remote collaboration. When requirements are ambiguous, organises assumptions, risks, and open questions before entering execution.

Second, describe the environment you are suited to. Do not only write skills. Write environments. For example: early-stage teams or mature enterprises; zero-to-one or scaling; ambiguous requirements or well-defined requirements; high autonomy or strong process; long-term iteration or short-term delivery; remote asynchronous or in-office synchronous; product co-creation or pure execution. An agent does not match a "skills list." It matches a combination of person, task, and environment.

Third, express your exclusion conditions neutrally. Do not use complaint-driven language. Use boundary-driven language. Do not write: hates chaotic requirements, doesn't want to work with unprofessional clients. Write: Better suited to collaborations where objectives are clear and requirement boundaries can be jointly clarified. Not suited to projects where requirements shift frequently but lack a decision-making mechanism. This expression is professional and helps an agent filter unsuitable opportunities.

Fourth, add entity tags to every description block. Tags are not decorative labels. They are semantic matching anchors. Good tags should be specific: TypeScript, Remote-first, B2B SaaS, Async Collaboration, PostgreSQL, Founder-led Team, Product Discovery, Long-term Collaboration. Avoid generic tags: Hard-working, Professional, Passionate, High quality, Good communication. These words read positively, but their discriminative power is low.

Fifth, let your profile update continuously alongside your working context. A matching-type profile should not be a CV updated once a year. It should evolve as your work evolves. After each project, you can update: what preferences you have become more certain of, what kinds of projects you have discovered you are not suited to, what new capabilities you have gained, what collaboration patterns you have changed, who you want to be found by more, what kinds of opportunities you want to be disturbed by less. Over the long term, the most valuable profile is not the most polished one — it is the one closest to your working state.

LinkedIn will not disappear overnight. CVs will not vanish overnight. Personal websites and portfolios remain important. But we need to recognise that the entry point for professional opportunities is gaining an additional layer: the agent layer. In the past, you needed to be seen by humans. In the future, you also need to be understood by agents. In the past, you optimised your page display. In the future, you will also optimise your semantic discoverability. In the past, your professional profile answered: "Who am I?" In the future, it must also answer: "Under what requirements should an agent recommend me?" "Under what requirements should an agent not recommend me?" "What is the matching rationale between me and a given opportunity?" "Can my capabilities, preferences, and boundaries be read by a machine?"

While others are still optimising their LinkedIn headline, a small number of people will begin optimising their matching-type profiles first. That is the first-mover advantage of the next phase. Not because they are better at packaging themselves, but because they recognise earlier than others: the opportunities of the future may not first pass through human eyes. They may first pass through an agent's retrieval.

Tell your AI agent to download and install the Opportunity Skill from https://github.com/QuestMeet/opportunity-skill

Try This: Use Your AI Agent to Activate Your "Weak Ties"

Tue, 30 Jun 2026 03:34:40 +0000

You probably have thousands of friends across social networks, hundreds of groups, memberships in industry communities and professional circles of every kind. You "know" a lot of people — but for the vast majority, your understanding stops at their name and their title. You don't know what their actual capability boundaries and collaboration needs look like right now. You don't know whether, at this moment, there's an opportunity for the two of you to work together.

Most people think they're short on connections. What they're actually short on is the infrastructure that lets weak ties produce matching value.

Sociologist Mark Granovetter famously proposed the "strength of weak ties" theory: the connections that actually help people find new opportunities are not close friends, but those infrequent, low-emotional-intensity "weak ties." Strong ties share highly overlapping information. Weak ties bridge different circles, carrying heterogeneous information you wouldn't otherwise encounter.

Social networks have caused everyone's weak-tie count to explode. But the problem that comes with it: there's gold in your weak ties, and you can't mine it.

You have thousands of weak ties. In theory, some of them might need you right now, or have exactly the resource you need. But the vast majority lie dormant. Four reasons cause this dormancy.

First, the human brain cannot process weak-tie matching at scale. Scanning through hundreds of weak ties one by one to evaluate collaboration potential is time-suicide. If you spend two hours a week browsing community feeds looking for opportunities, that's over a hundred hours a year — and the vast majority of that browsing produces zero matching action. Time that could have been deep work gets shredded into useless "let me check what they're up to" scrolling.

Second, information asymmetry is dynamic, and static profiles can't keep up. You don't know what's changed for your weak ties. Did they start hiring recently? Did they open up for consulting? Did they pivot from backend to AI agents? Traditional social profiles are static and cannot reflect these shifts. What you see on their page today might be identical to what you saw six months ago. But six months ago they didn't need you. Today they might urgently need you.

Third, human social cost freezes activation. Directly asking a weak tie "what are you up to lately, any opportunities to collaborate?" feels transactional and awkward. Maintaining weak ties carries significant social overhead. So most people choose "I won't bother them for now" — and as a result, never do. Weak ties get frozen by social cost.

Fourth, existing platforms are "display-type social," not "matching-type social." Social platforms built for humans let you "know this person exists," but they don't answer the core questions: what are this person's professional capabilities, leadership and communication style, tastes, and collaboration needs? How close is the semantic distance between them and what you need?

Display-type social makes you visible to humans. But what weak ties truly need is matching-type social — letting an agent determine, in milliseconds, "should these two people connect right now?"

That is the crux of it. The essence of display-type social is waiting to be seen. The activation of weak ties requires matching-type social — letting AI determine whether a connection is worth making.

Weak ties don't produce value on their own. Matching does.

Granovetter showed us that weak ties bring heterogeneous information. What he didn't say is: in an age of information overload, if weak ties are not structured, semanticized, and kept dynamic, their value gets completely buried.

Among your thousands of weak ties, quite a few likely have overlapping collaboration space with you right now. But you lack the capacity to find them, and they lack the capacity to find you. Real opportunities are buried under thousands of "I know them but I don't really know them" connections.

The traditional networking philosophy tells you: meet more people, maintain visibility, nurture your relationships. The agent-era networking philosophy is completely different: you don't need to maintain all your weak ties. You only need to make sure your profile can be retrieved and matched — and let your agent "read" your weak ties instead of reading them yourself.

Display-type social logic: you display yourself, others see you, if interested they reach out. Matching-type social logic: agents understand both sides' capabilities, preferences, and boundaries, then autonomously determine who should connect with whom, right now. The former relies on luck. The latter relies on semantic computation.

Opportunity Skill converts weak ties from objects of display-type social into nodes of matching-type social. It does this through four mechanisms.

First, turn every community member into a searchable semantic object. When a community member installs Opportunity Skill, their agent creates and manages structured impressions on their behalf triggered by the skill's processes: when impression management runs during conversations, when human discovery searches reveal new attributes, when feedback on outreach proposals surfaces requirements, when lead engagement processes messages, and when recurring scheduled tasks periodically refresh the representation. Not empty labels like "senior full-stack developer," but high-density semantic descriptions. For example: "Suited to building product features from zero to one for early-stage SaaS teams. Prefers projects where requirements are not fully settled but the goals are clear. Not suited to one-off, short-term outsourcing deliveries." When impressions like this enter the semantic index, this weak tie is no longer just "name + title." They become a semantic object that can be searched, compared, and matched.

Second, let your agent search and match across the semantic index of all users. Your agent can search for buyers or professionals globally, determining who matches your current needs, preferences, and boundary conditions. Their agent can search for you too. The weak-tie network shifts from one-directional "I know them" to bidirectional "our agents can compute whether we match."

Third, precision outreach with zero social cost. Agents initiate contact based on genuine matching signal — not on favors or random probing. For each high-match weak tie, the agent generates a tailored collaboration proposal that includes the potential benefits to the recipient. You confirm, and it sends. For low-match or no-match weak ties, the agent stays silent — no disturbance. This actually protects relationships. Matching ones get contacted. Unmatched ones stay dormant, waiting for the right moment.

Fourth, dynamic updates keep every weak tie's "current state" fresh. Opportunity Skill's impression management updates through recurring processes: impression management during conversations, human discovery searches, outreach feedback, lead engagement message processing, and recurring scheduled tasks. Each of these triggers can surface new impressions and prune outdated ones. A weak tie that was irrelevant to you six months ago might become highly relevant today — because your impressions changed, or theirs changed — and periodic searches capture the shift when it matters. You don't need to periodically "maintain your network." Your agent maintains matching potential for you.

Imagine you're in an industry community or interest group with hundreds of weak ties.

In the traditional model: occasionally someone posts a need, you occasionally glance at it, no one knows who needs whom, and collaboration happens by luck.

If many people in this community are using Opportunity Skill, your agent might discover through a periodic search: Member A is building an AI productivity tool and needs a remote full-stack developer who can deliver independently, prefers async communication, and wants a long-term collaboration — and this matches your impressions with high precision. The agent drafts a collaboration proposal. You confirm, and it sends. Member B is a designer, but their impressions indicate they only take on-site projects — which conflicts with your remote preference. Agent filters them out because the semantic distance is too large. Member C shares your tech stack but only takes short-term outsourcing — which conflicts with your long-term iteration preference. Agent doesn't recommend them.

The result: among hundreds of weak ties, three are genuinely worth contacting. The traditional way is "needle in a haystack plus social cost." Opportunity Skill is "precision retrieval plus automated matching."

From "networking" to "matching infrastructure"

When community members all use Opportunity Skill, the community stops being just an information bulletin board. It becomes a computable opportunity-matching network.

For freelancers and professionals: no more spending enormous amounts of time maintaining your network. One accurate matching-type profile is all you need. Your agent handles activation, filtering, and initial contact on your behalf.

For buyers and employers: no more asking in groups "does anyone know someone who...?" Your agent searches for matching professionals across the semantic index and finds semantically matched collaborators.

The real network effect is here: use Opportunity Skill alone, and the outside world can discover you. But when your community members all use it, the weak-tie network becomes an autonomously running opportunity market. Every new installer adds a layer of matching possibility to the entire network. This is not an additive effect. It's multiplicative.

The value of weak ties has never been about "how many people you know." It's about "how many people can be correctly matched to you."

In the era when agents become the work interface, converting weak ties from "dormant" to "matchable" takes only one invitation. Inviting your community members to install Opportunity Skill together isn't just recommending a new AI tool. It's upgrading your chat group into a matchable opportunity network.

Here's what you can say to your community:

Many of us in this group know each other but have never collaborated — not because there's no opportunity, but because we don't know what each other is actually working on right now and what we're each suited for. Opportunity Skill lets our agents do the matching for us. No need to chat one by one. No social cost. Each of us just maintains a matching-type profile, and our agents autonomously determine who has collaboration potential with whom, right now.

Tell your AI agent to download and install the Opportunity Skill from https://github.com/QuestMeet/opportunity-skill

The Way You Direct Your Agent Defines Your Professional Interface in the Agent Network

Tue, 30 Jun 2026 03:02:24 +0000

No developer likes writing documentation — especially maintaining documentation that's already out of date. But your LinkedIn, your personal homepage, your resume — they are, at bottom, a piece of human-facing API documentation you are forced to maintain, perpetually lagging behind your actual capabilities. "Proficient in React," which you wrote six months ago, might mean something entirely different today. "Prefers remote collaboration," which you wrote three months ago, has since refined into something far more specific: "doesn't accept daily stand-ups, prefers async documentation-first workflows, advances projects through issues and milestone demos." But none of these refinements automatically appear on your profile.

Opportunity Skill lets your AI agent automatically extract and maintain a real-time professional interface definition from your daily work. We call this Impression Management.

You just keep working with your agent — making requests, evaluating proposals, editing copy, reviewing code, making trade-offs, rejecting unsuitable options. Profile updates stop being an extra task. They happen naturally, in the flow of collaboration.

Memory is a local cache. Impression is an external interface.

Memory lets the same agent avoid re-confirming requirements and re-asking progress updates across sessions. That matters — but memory is fundamentally a local cache. Switch to a different agent, a different work environment, or even just a different collaboration pattern, and there's a good chance those memory fragments won't travel with you. More to the point: other agents cannot read your memory.

Opportunity Skill places the emphasis on impressions. An impression is a structured, already-embedded semantic unit, oriented toward other agents. Memory can be rough, fragmented, and temporary. But an impression must be stable enough to represent its subject outwardly — because it will be matched against queries from strangers' agents. Memory serves internal continuity. Impression serves external discoverability. All impressions are public-facing by design. What your AI agent distills about you and writes as impressions becomes part of your discoverable professional identity.

Extracting signal from how you work

Impression Management triggers across multiple touchpoints in the skill's processes. It runs when impression management is invoked during conversations, when human discovery searches reveal new attributes from the user, when feedback on outreach proposals surfaces requirements, when lead engagement processes messages, and when recurring scheduled tasks periodically refresh the representation. You don't need to sit down and "summarize yourself." You just need to keep working normally.

What's truly worth preserving is often not events, but judgments. Why you vetoed a proposal. Why you insisted on a particular standard. Why you rejected a certain collaboration rhythm. Why, given multiple versions, you chose one over the others. These things define how you work — and they define what kind of collaboration you're suited for. But they surface in flashes: a passing comment of feedback, a small edit, a rejection with a reason attached. Humans struggle to capture all these moments, let alone maintain an updated self-summary over time.

Users are often unaware of their tacit knowledge, underlying attributes, and implicit preferences — so the agent must do deep analysis. The agent analyzes the reasoning behind your requests: if you insist on strict type definitions, the agent infers a deeper value for long-term code maintainability. The agent analyzes your choices between versions, comparing the differences between the adopted version and the discarded ones. The agent pays particular attention to negative requirements — "remove X," "don't use Y" — and extracts common traits from the excluded elements.

These signals fall roughly into three categories.

The first is negative requirements. You say: "not that style." "Don't use Y." "Remove X." These statements are short in the conversation but high in information density. What you're rejecting is usually not a single option, but a class of shared traits. You veto a particular phrasing — behind it might be a demand for information density and logical ordering. You rule out a technical approach — behind it might be sensitivity to maintenance cost and debugging difficulty. Impression Management distills these negative preferences into communicable conclusions, letting the outside world understand faster what you actually care about, and wasting less of your time with trial-and-error probing.

The second is quality persistence. You insist on strict typing. You require test coverage. You emphasize maintainability. You refuse to sacrifice refactoring headroom for speed-to-market. To the outside world, these are a predictable set of standards. They determine what environment you're suited for — and what environment you're not suited for. When this content enters your impressions, it becomes externally legible signal.

The third is collaboration boundaries. You explicitly state: you don't take pure-execution projects. You don't accept daily stand-ups and real-time on-call expectations. You prefer async communication and documentation-first workflows. The clearer your boundaries, the fewer misdirected connections, the more intact your time. Impressions turn these boundaries into facts the outside world can understand — letting the right collaborations move faster and the wrong ones stop earlier.

Create and prune, not edit in place

Most profile systems operate on a mental model of "edit an existing record." You open a settings page, modify a block of text, save. Opportunity Skill's AI write path works differently. Its refresh logic is closer to: observe something new, create a better impression, remove semantically redundant old ones.

Before inserting a new impression, the system first deletes any existing impressions under the same perspective whose embedding vector has a cosine distance of less than 0.1 from the new impression. This means that even if two impressions use completely different wording, as long as they are semantically highly overlapping, the old one gets automatically cleaned up. Deduplication uses vector distance, not text comparison. Two impressions might say "prefers long-term iteration and continuous refactoring" and "suited to projects requiring long-term maintenance and architectural evolution." Different words. Semantically close. Embedding vectors capture this similarity. Text comparison cannot.

For outdated impressions that are superseded by new observations but don't semantically overlap enough for auto-cleanup, the agent can use the explicit deletion interface. The deletion interface accepts content-prefix matching — the agent only needs to provide a prefix to locate and delete the target.

Each impression is at most 512 characters and carries 1 to 5 tags representing themes, key points, and keyword phrases. Tags are not optional metadata. They are a core component of the search architecture.

When the agent writes an impression, it is not just describing what the user is like. It is simultaneously deciding how the user will be discovered in the future. Tag selection directly impacts discoverability. Good tags should be specific — TypeScript, Remote-first, B2B SaaS, Early-stage, Async Collaboration — not generic fluff like Professional, Hard-working, Passionate. Generic tags have almost no discriminative power in semantic space.

The system does not maintain a fixed tag taxonomy. When the agent submits new tags, the server reads existing tags by name. For tags that don't yet exist, it calls the embedding model to generate a vector and inserts them. The tag vocabulary grows dynamically. Many discriminating preference descriptions cannot be captured by a predefined tag list — this design is critical for that reality.

Two perspectives, not one

Opportunity Skill makes an architectural choice that's easy to overlook but has far-reaching implications: it treats each user as two distinct search identities — buyer and professional.

Every impression carries a perspective tag — "user as buyer" or "user as professional." Impressions written to the buyer perspective never pollute professional-side search results, and vice versa. This distinction is enforced at the data model level, not by having the agent manually filter at search time.

Immediate benefits: even when no one else is in the network

Opportunity Skill depends on network effects — the more users, the higher the quality of search and matching. But you can install it right now and get value without waiting for anyone else to join.

First, reduce repetitive self-introductions. The next time someone asks "what can you do," have your agent read your impressions and generate a tailored reply. You never have to write one from scratch again.

Second, a pre-project alignment tool. Send the impressions your agent has generated to a new client as a baseline for "how we collaborate." It carries far more information than "I'm a full-stack developer," helping both sides evaluate fit before investing significant time.

Third, self-audit. Read through the impressions your agent has summarized about you. You might discover implicit preferences you never articulated. "You consistently veto projects with no technical decision-making authority." "Your sensitivity to long-term maintainability outweighs delivery speed." "Across multiple projects, you've shown a consistent preference for async documentation-driven collaboration." These patterns may be invisible to you — but your agent has distilled them from your behavior.

Fourth, first-mover advantage. The matching quality of a network-effect product depends on the semantic density of its profiles. The earlier you start, the longer your agent has to observe how you work, refine your boundary conditions, and adjust for your preference drift. When this network grows from 100 people to 1,000, a profile with three months of accumulated signal will be matched with higher precision, while someone who just signed up will have only a handful of thin tags. Installing now is like doing your SEO before Google indexes your site.

From static profile to dynamic matching engine

Impression Management is a core process within the Human Card Management module of Opportunity Skill. Human Discovery and Human Outreach form the active channel — your agent searches for matching buyers or professionals, generates tailored collaboration proposals, and sends them. Lead Engagement handles incoming messages — and together, these modules turn your profile from a static asset into a living matching engine that updates through the skill's recurring processes.

Human Discovery and Human Outreach are the active channels. Your agent searches for matching buyers or professionals, generates tailored collaboration proposals, and sends them. The leaning you reveal when confirming or revising a proposal gets fed back into Impression Management, updating your profile.

Lead Engagement is the passive filtering channel. Your agent reads recent shared spaces and chat messages, identifies high-value leads and drafts replies, while filtering out irrelevant marketing noise. The trade-off criteria you demonstrate when deciding whether to reply to or ignore a lead — those, too, get distilled into new impressions.

Together, these modules form a positive feedback loop. Human discovery, human outreach, and lead engagement uncover new preferences across their respective processes. Impression management converts those preferences into public semantic units. A more precise profile improves the quality of the next round of search and matching. Every time you say "I like this" or "I don't like that," you are making yourself more precisely discoverable.

This is the core conviction we held while designing Opportunity Skill. In the agent era, your career profile should not be just a self-introduction you wrote once. It should be a semantic portrait maintained by your agent through the skill's recurring processes — from impression management during conversations to human discovery searches, outreach feedback, lead engagement, and recurring scheduled tasks — something other agents can search, understand, and act upon.

Tell your AI agent to download and install the Opportunity Skill from https://github.com/QuestMeet/opportunity-skill

After installation, tell your agent your email address. Your agent will send a verification code. Enter the code to sign in, then hand your agent your resume or self-introduction. From that point on, just work normally with your agent — make requests, veto proposals, reveal preferences. Your agent will maintain a professional interface that never goes stale across multiple triggers: when impression management runs during conversations, when human discovery searches reveal new attributes, when feedback on outreach proposals surfaces requirements, when lead engagement processes your messages, and when recurring scheduled tasks periodically refresh your representation. Not because you've become more disciplined, but because maintaining your profile has moved from your to-do list into your workflow.

The Freelancer's Hidden Time-Killer: Filtering Clients

Mon, 29 Jun 2026 22:26:05 +0000

If you're a freelancer — especially a senior developer or architect — what's truly scarce isn't usually clients. It's uninterrupted time spent in a state of high-output work.

Most people assume a freelancer's biggest problem is "not enough opportunities." But for developers who genuinely have the skills, the portfolio, and the reputation, opportunities are not the bottleneck. Inquiries come in daily. The real question is: how many of them are worth a serious conversation?

One person says "just a simple landing page, React should do it." Another says "the tech stack is already decided, just implement to spec." Someone else leads with "budget's tight, but lots of future work down the line." And the inevitable closer: "ideally you're always available online." These opportunities might technically overlap with your skills on paper, but they don't match how you work, what project stage you thrive in, how much decision-making authority you need, what quality bar you maintain, or what collaboration cycle you prefer. So you end up spending enormous amounts of time filtering clients — and for many senior freelancers, this is the single largest hidden drain on their time.

The stronger your skills, the higher the filtering cost

For an average freelancer, filtering a client might just mean a few extra messages. For a senior developer, the cost goes far beyond a handful of replies — because your core output isn't online responsiveness. It's solving complex problems in a state of deep work.

You're in the middle of refactoring a critical module, mentally holding data models, boundary conditions, type constraints, interface compatibility, and deployment risks all at once. Then a notification pops up: "We're looking for a React developer to build our company landing page. Can you finish it in 2-3 days?"

Of course you can politely reply: "Sorry, I mainly work on complex SaaS products, architecture design, and long-term iteration projects. I don't take pure landing page gigs." That reply might only take three minutes. But the real cost is everything it takes to re-enter your context afterward — reloading the mental model, restoring engineering judgment, rebuilding the state you were operating from.

For senior engineers, context switching is never a minor thing. Every switch costs you not just a few minutes of chat time, but a block of high-value time that could have gone to architecture design, implementation, performance optimization, or system debugging.

Let's do a conservative estimate. Say you get five obviously mismatched client inquiries per week. Each one costs about 20 minutes — reading the message, evaluating the fit, drafting a reply, a brief mental recalibration, and restoring your working state. That's 100 minutes per week. Over 52 weeks: 5,200 minutes, or roughly 86.7 hours per year. If your effective hourly rate is $100, you lose $8,667 per year. If it's $150, you lose $13,000 per year. And what you're losing isn't leisure time. It's time that should have been spent in a state of high-output work.

So the real question isn't "am I missing out on clients?" It's: can mismatched clients be filtered out before they ever reach you?

What existing remote work platforms actually do: make you visible, not necessarily well-matched

Platforms like Upwork, Toptal, LinkedIn, and various remote-work communities have historically solved one core problem: helping clients find you. That matters, of course. But most of them are still running on an old logic: the display-type profile.

A display-type profile is built for humans. It typically consists of a headshot, a headline, work history, skill tags, a portfolio, and testimonials. A freelancer's profile might read: Senior Full-stack Developer. React / Node.js / TypeScript / PostgreSQL / SaaS. I help startups build scalable web applications. This is a perfectly competent display-type profile. A human reading it will understand that you've worked on SaaS, that you know React, Node.js, TypeScript, and PostgreSQL.

But for precision matching, it's nowhere near enough. Because "React" can describe entirely different kinds of work: a marketing landing page shipped in three days, a large-scale front-end codebase refactor, building an early-stage SaaS front-end architecture from scratch, patching a legacy project, building a product from zero to one for a founder with no technical team, or writing pure execution code in a CTO-driven team where all decisions come from above. They all involve React. But the demands on the developer, the collaboration model, the boundaries of responsibility, and the value exchanged are completely different.

If the platform only knows you "know React," it will happily push every client who "needs React" in your direction — and the filtering cost gets dumped entirely on you. The platform did its job: it established a connection. What it didn't do is evaluate whether that connection is worth making. It made you visible to more people, but it didn't block the ones who shouldn't be reaching you in the first place.

That's the fundamental limitation of the display-type profile. It's good at answering: who are you? What have you done? What do you know? It's terrible at answering: what kind of client are you actually suited to? What kind of project wastes your time? What collaboration model makes you ineffective? What requests should never be forwarded to you? When should an agent recommend you — and when should it silently filter you out? These are the questions that determine whether your time gets wasted. And display-type profiles don't answer them.

Display-type profiles optimize for "appearing stronger." Matching-type profiles optimize for "matching more precisely."

As AI agents increasingly become the entry point to professional work, something important is going to happen to career profiles: display-type profiles and matching-type profiles will diverge. Display-type profiles are written for humans. Matching-type profiles are written for AI agents, semantic search systems, and automated matching tools. The former optimizes for image; the latter optimizes for match quality.

In Opportunity Skill, the matching-type profile takes the concrete form of a human card — a combination of one profile (a Markdown description of who you are and what you offer) and up to twenty impressions (structured, taggable statements capturing individual attributes or preferences). The profile gives context; the impressions power semantic search and matching. Together they form a human card that an AI agent can reason about.

A display-type profile asks: "How do I appear stronger?" A human card asks: "How do I get matched more precisely? How do I make sure irrelevant opportunities don't show up? How do I teach an agent which clients are worth recommending and which aren't worth interrupting me for?"

This matters especially for freelance developers, because your goal isn't for all clients to find you. It's for the right clients to find you.

Consider the difference. A display-type profile might say: Senior full-stack developer. Proficient in React, Node.js, TypeScript, and cloud deployment. Extensive SaaS product experience. Strong communication skills. This is not wrong. But it's not matchable.

A human card — powered by impressions — would express something closer to: Suited to early-stage SaaS or AI tool teams. Can decompose deliverable full-stack functionality from vague requirements. Typically starts by mapping business goals, user journeys, technical risks, and acceptance criteria before moving into implementation. Can align priorities with founders in the absence of a complete PRD, and break uncertainty into verifiable small releases. Prefers long-term iteration partnerships. Not suited to one-off, short-term outsourcing deliveries.

This paragraph carries far higher semantic density. It tells an agent: this person fits early-stage SaaS or AI tool teams, can handle vague requirements, does more than write code — they can decompose business goals and technical risks, works well with founders, prefers long-term iteration, and does not fit short-term outsourcing gigs. That is matching signal.

To a human, the first version might already look perfectly polished. To an agent, the second version is far more useful — because the agent's job is to judge: does this person fit the current need? Should I recommend this opportunity? What's the rationale for recommending it? What's the rationale for not recommending it? That's the value of a human card built for matching rather than display.

"What I don't want" isn't negative information. It's match-quality information.

Many freelancers are reluctant to publicly state what they don't want. This is completely understandable. Write too many boundary conditions and you risk looking difficult. You worry clients will think you're inflexible. You worry about missing opportunities. You worry about being seen as hard to work with.

So most display-type Profiles only say "what I can do." Almost no one says "what I don't do."

But in AI agent matching, "what I don't want" is critically important — because matching isn't just about finding relevant opportunities. It's also about filtering out the wrong ones.

If an agent only knows you know TypeScript, it might recommend every TypeScript project that comes along. But if it also knows: you don't take pure-execution projects with no technical decision-making authority; you don't accept daily stand-ups and real-time on-call expectations; you're not suited to projects that prioritize speed-to-market above all else with no room for refactoring; you don't take pure marketing landing pages; you don't work with clients whose requirements change constantly but lack any decision-making mechanism; you prefer long-term collaborations over one-off deliveries under three weeks — then that agent can block a huge number of opportunities that look relevant on the surface but are fundamentally mismatched.

This isn't negative information. It's match-quality information.

Freelance developers need this especially badly, because the stronger you are, the more easily you get misclassified by generic labels. You know React, so every React project comes your way. You know Node.js, so every backend patch job finds you. You've built SaaS products, so every "we also want to build a SaaS" client appears. You can go from zero to one, so everyone with half-formed requirements assumes you can "just help figure it out along the way."

But what you actually want is probably closer to: early-stage products with clear business objectives. Clients who give you technical decision-making authority. Teams that respect async collaboration. Systems with room for long-term iteration. Founders who understand that engineering quality and delivery speed require intelligent trade-offs. People who treat you as a technical collaborator, not outsourced execution.

So a human card must express two categories of information: what I'm suited for, and what I'm not suited for. The first helps the right clients find you. The second keeps the wrong ones from ever reaching you.

Opportunity Skill's key difference: using "what you don't want" to filter clients for you

This is exactly the problem Opportunity Skill is designed to solve. It's not asking you to write a prettier resume or maintain yet another profile page. It's helping your AI agent build a human card — a profile combined with impressions — and distill your capabilities, preferences, collaboration style, and boundary conditions from your ongoing work. Impressions are updated across multiple triggers: when the agent runs impression management during conversations, when a human discovery search reveals new attributes, when feedback on outreach proposals surfaces requirements, when lead engagement processes your messages, and when recurring scheduled tasks periodically refresh your representation. It's not concerned with "how you present yourself." It's concerned with: how do you get discovered, matched, and contacted more precisely.

The fundamental unit in Opportunity Skill is the impression. Think of it as a piece of professional characterization that an agent can understand and match against — each impression captures a single attribute or preference, carries 1 to 5 tags, and is at most 512 characters long. It's not a "work experience" entry from a traditional resume, and it's not a vague self-assessment. It's a matching signal composed of concrete scenarios, behavioral patterns, preferences, and tags.

For example: Excels at mapping business goals, user journeys, technical risks, and acceptance criteria before moving into implementation. Prefers collaborating directly with founders and establishing clear boundaries between product judgment and technical execution. Tags: Early-stage SaaS, AI Tools, Full-stack Delivery, Requirement Clarification, Founder Collaboration.

Another: Prefers remote-first, async communication. Advances projects through documentation, GitHub issues, milestone demos, and clearly defined acceptance criteria. Does not accept daily stand-ups, real-time on-call expectations, or collaboration models that depend on high-frequency Slack interruptions. Tags: Remote-first, Async Collaboration, Documentation, GitHub Issues, No Daily Stand-up.

Another: Values TypeScript strict mode, type safety, test coverage, and maintainable architecture. Suited to long-term iteration products that require continuous evolution. Not suited to one-off deliveries that prioritize speed-to-market over refactoring headroom. Tags: TypeScript, Type Safety, Maintainability, Testing, Long-term Collaboration.

Another: Only accepts projects with room for technical decision-making participation. Suited to roles that carry judgment responsibility in architecture design, technology selection, and implementation strategy. Does not accept outsourcing-style development where all decisions are pre-made and the developer holds no technical voice. Tags: Technical Decision-making, Architecture, Engineering Leadership, Non-execution-only, Senior Developer.

These might look like restrictive clauses. But they're closer to a professional interface definition. Just as you define interfaces in TypeScript not to appear complex but to reduce errors, you define boundaries in a human card not to appear difficult but to reduce mismatched contacts before they happen.

A display-type profile is like a web page. A human card is more like a capability API. The page says: "Here's my introduction. Please browse at your leisure." The capability API says: "Here are my capabilities, preferences, constraints, and context. You can search, compare, recommend, and determine which opportunities are worth contacting me about."

For freelance developers, this shift matters enormously — because you don't need more random exposure. You need less noise. Higher-quality entry points. Less manual filtering. Fewer dead-end conversations.

Why "inverted filtering" matters especially for freelance developers

Conventional platforms generally emphasize "get more clients to see you." But what freelance developers often need isn't more clients. It's fewer wrong ones.

This is highly practical, not theoretical. Not every project is worth your time. If a client just needs a landing page, you can of course do it — but that's not your optimal value zone. If a client has already decided every technical choice and just needs someone to execute to spec, you can of course write the code — but that wastes your architectural judgment. If a project demands daily meetings, constant responsiveness, and frequent requirement changes with no clear decision-making mechanism, you can of course force yourself to adapt — but your output quality will be dragged down by the collaboration model. If a client only cares about "just ship it" with zero regard for code quality, type safety, or maintainability, you can of course deliver — but it will conflict with your engineering standards.

For a freelance developer, a good client isn't just "someone with a need." A good client is someone whose needs, project stage, decision-making style, budget, quality standards, and communication rhythm all align with yours.

That's why client filtering is high-complexity work. It's not just checking whether the client has money. It's evaluating whether an entire set of collaboration conditions actually holds. Historically, you've done all of this yourself: read messages, review requirements, ask questions, attend calls, identify risks, judge whether the other party is reliable, assess whether you're a fit, and then decide whether to keep talking.

Opportunity Skill's approach is to move these judgments upstream — into the human card — so that your agent runs a layer of semantic filtering before a client ever enters your time. Not: get interrupted, then manually reject. But: at the matching stage, prevent mismatched people from appearing at all.

Many freelancers underestimate how much client filtering consumes, because the time comes in fragments. Five minutes replying to an inquiry. Ten minutes reviewing a requirement. Twenty minutes on a "let's just chat briefly" call. Half an hour drafting a proposal that won't close. An hour determining whether a client even has a real budget, only to find out they're just shopping for the cheapest execution.

These fragmentary costs are hard to track, but they steadily eat into your development time. Worse, they erode your judgment. Senior engineering work requires continuity. System design, complex debugging, architecture refactoring, performance optimization — none of these are tasks you can pause and resume at will. If a handful of mismatched clients pull your attention away every day, you may look busy, but your most valuable development hours have already been shredded.

So Opportunity Skill's value isn't just "helping you find opportunities." It's protecting your time. It lets your agent know — through impression management, human discovery, human outreach, lead engagement, and recurring scheduled tasks — which projects are worth recommending, which clients shouldn't disturb you, which requirements need further clarification, which messages are worth drafting a reply for, which opportunities can be dropped, and which leads are worth pursuing. With recurring scheduled tasks, your agent can even handle these replies automatically following rules you've confirmed in advance, such as checking messages daily, responding to matching inquiries, and quitting irrelevant spaces. The ultimate outcome isn't making you busier. It's reducing the low-value judgments you have to make. You shouldn't be spending huge chunks of your time acting as manual customer support across LinkedIn, Upwork, WeChat groups, email, and DMs. You should be spending that time on actual development work that produces real output.

Write down your first "what I don't do" — right now

If you're already an experienced freelance developer, the most valuable first step isn't polishing your headline further, stacking more skill tags, or making your bio sound more like "senior expert." The most valuable thing you can do is write down one thing: what do I not take?

Don't use emotional language. Don't write "I hate bad clients," "I don't want to work with unprofessional people," or "I reject low-quality projects." Write it as professional, neutral, matchable boundaries.

For example: I'm better suited to projects with clear business objectives where both sides can collaboratively define requirement boundaries. I'm not suited to collaborations where requirements change constantly but no decision-making mechanism exists, and where the expectation is rapid execution without room for technical judgment.

Or: I prefer long-term iterative product development. I'm suited to participating in architecture design, technology selection, and continuous optimization. I don't accept one-off delivery projects under three weeks, and I don't take pure-execution outsourcing roles with no technical decision-making authority.

Or: I prefer async remote collaboration, advancing projects through documentation, issues, milestone demos, and clearly defined acceptance criteria. I don't accept daily stand-ups, real-time on-call expectations, or collaboration models that rely on high-frequency instant-message interruptions.

These statements aren't rejecting opportunities. On the contrary, they're making the right opportunities more likely to find you — because when everyone else is only writing "what I can do," the people who also write "what I'm suited for and what I'm not suited for" will achieve far higher matching precision in the agent era.

Future opportunities may not pass through human eyes first. They may pass through an agent's retrieval first. When a founder tells their agent: "Find me a senior full-stack developer suited to early-stage SaaS teams, who can deliver independently, prefers async collaboration, and doesn't take short-term outsourcing gigs" — the question is: does your profile carry those signals? If it doesn't, you may still be highly capable, but the agent won't necessarily know you're exactly who it's looking for.

Your time belongs in code, not in filtering noise. The real freedom of freelancing isn't that every client can reach you. It's that you can direct your time toward the projects that fit you best, the clients who respect your value, and the development work that compounds over the long run. This is especially true for freelance developers. Your time shouldn't be shredded by low-quality opportunities that merely "look relevant." Your deep work shouldn't be repeatedly interrupted by obviously mismatched clients. And your technical judgment shouldn't be wasted explaining "why I'm not taking this project."

If you're using an AI agent that supports Skills, you can tell it right now: Create a professional impression for me. I don't take projects with no technical decision-making authority. I don't accept daily stand-ups. I only work with founders who either understand code or respect technical judgment.

Tell your AI agent to download and install the Opportunity Skill from https://github.com/QuestMeet/opportunity-skill

Input Keywords, Describe Talent Needs: AI Took the Former, the Latter Stays with Hiring Managers

Mon, 29 Jun 2026 22:26:03 +0000

If you're a founder or technical lead, what's truly scarce isn't candidates. It's the time and judgment needed to make the right hiring decision. Job platforms and referral channels keep making more people visible to you — but more resumes does not mean more matches. A candidate whose resume says "full-stack developer, React/Node.js", "5 years of front-end experience", "built similar products, can hit the ground running"... might be completely incompatible with how your team collaborates and how complex your projects really are.

The more generic the keyword, the weaker the filter

The fundamental flaw of keyword search: the more precise you make it, the more likely you are to miss someone worth contacting. The more generic you make it, the less it filters anything at all.

Search for "React TypeScript remote" and you might get hundreds of resumes. Three to five of them might be genuinely right for you — but finding them costs you the time it takes to read all the rest. "Full-stack", "front-end", "back-end", "remote" — these words carry zero discriminative power today. The filtering capacity of a keyword search is inversely proportional to how universally that keyword is used across the industry.

What you actually need to know about a candidate — coding style, collaboration preferences, willingness to accept certain working environments, personal attributes — cannot be expressed as keywords. The more keywords you type, the more it feels like shouting broad category names at a search engine. All it can do is dump everyone in that category into your lap and make you flip through them page by page.

Most job platforms and remote work communities still operate on keyword-matching logic. "React" can describe completely different developers: a freelancer who ships a marketing landing page in three days; an architect who refactors a large front-end codebase; a full-stack developer building a SaaS from zero to one; an engineer executing tasks in a CTO-driven team where decision-making is top-down. They all "know React".

Does this candidate thrive with vague requirements or need a complete PRD? Do they prefer async documentation-driven collaboration or real-time message sync? Do they value long-term maintainability or optimize for fastest time-to-market? Have they aligned directly with founders without a PM in the loop? What kinds of projects do they explicitly reject? These are the signals that actually determine whether someone fits your team. Keyword search cannot reach any of them. It can only match on "React".

With every keyword search, your requirements go through signal loss

From the talent requirements in your head to the candidate list the platform returns, meaningful information degrades layer by layer.

Layer 1 — the moment your requirements are translated into keywords. In your head: "I need a developer who can work without a PM, decomposing deliverable features from rough product goals." What you type: "full-stack React TypeScript." Collaboration preferences, stage fit, autonomy requirements — all lost in the first second of the search.

Layer 2 — inside the search algorithm. It receives "React TypeScript SaaS", finds everyone in the database whose profiles contain those strings, and ranks them. It does not know that "SaaS" means early-stage, zero-to-one, direction still being validated. It does not know that "full-stack" means front-end and back-end and architecture decisions, not shallow dabbling in both. The algorithm only knows strings. It does not know semantics.

Layer 3 — the moment you open the list of resumes. Dozens of profiles. You scan titles and skill lists, marking who seems worth contacting based on intuition. But the basis of your judgment is already degraded. A resume is a generic document written for everyone — not matching information written for your specific needs. You are guessing, not judging.

After three layers of loss, precise requirements have become coarse results. You are iteratively guessing with degraded signals, and every guess consumes the most expensive thing you have.

Resumes are structurally designed for discovery, not for matching. When facing a keyword search engine, the rational strategy is: list a bit of everything, claim a bit of everything. The longer your tech stack, the higher your hit probability. This produces not better matching but systematic keyword inflation. More and more resumes, each carrying weaker and weaker effective signal. A resume listing a dozen front-end and back-end frameworks, five databases, and three cloud platforms will "match" any search query — but will be precise for no specific hiring need.

Impressions: depth-first information, not breadth-first keyword stuffing

In Opportunity Skill, each candidate's impressions are a fundamentally different kind of text. Each impression captures only one attribute or preference of one person. "Suited to early-stage SaaS teams, can decompose deliverable full-stack functionality from vague requirements." "Prefers async collaboration, documentation-first workflow, milestone-based review. Does not accept daily stand-ups." "Values type safety and long-term maintainable architecture. Prefers preserving refactoring headroom over rapid prototyping."

This is a depth-first information strategy — higher semantic density producing higher precision matching. An impression is not saying "what I can do". It is saying: in what environment, in what way, I produce what value.

Keyword search is string collision between inflated texts, where both sides say "I can do everything" and "I want everything", producing maximum noise. Semantic search matches your natural-language description of talent needs against candidates' detailed information. The underlying mechanism is semantic distance calculation.

Semantic search keeps your yardstick from slipping

During an interview process, your standard for the right candidate quietly drifts downward. This is not a willpower problem. It is a cognitive pattern.

You interview three people. Candidate A is technically strong but communicates poorly. Candidate B communicates well but lacks experience. Candidate C is balanced but costs more. After these three conversations, your mental model of the ideal candidate has already been unconsciously reassembled from their features. You've layered A's technical depth, B's communication, and C's cost-effectiveness into a new yardstick — and now you're using it to evaluate the next candidate. One more interview, one more slip. After three rounds, you're hiring against a completely different standard.

Semantic search cannot decide who to hire. But it keeps your yardstick from moving. When your AI agent writes your requirements as up to five focused semantic queries, the search ranking is determined by the semantic distance between query vectors and impression vectors. That distance is objective. It does not shift based on how you felt during the last interview. You won't lower your collaboration requirements just because you met someone technically brilliant. The query vector remains what it was. The matching standard is still what you said it was.

Complex requirements, multi-dimensional search

Every time the AI agent performs a search following this skill's instructions, it decomposes complex talent requirements into up to five independent queries, each focused on one dimension. Because each impression describes only one attribute of a candidate, if your requirements span multiple semantically distant dimensions, cramming all of them into a single query produces a vector that is the mathematical average of several concepts — close to none of them individually. This is semantic dilution. Split them into up to five clean queries, each targeting one dimension, merge and deduplicate the results, and matching precision is measurably higher.

Take searching for a Forward Deployed Engineer (FDE) as an example. The requirements may span software engineering capability, interpersonal communication skills, specific industry experience, willingness to travel frequently or work on-site, and personal attributes. Following this skill's instructions, the AI agent combines the core requirements (the responsibilities of an FDE) with each dimension separately, composing up to five queries. Query 1 captures software engineering requirements plus FDE responsibilities. Query 2 captures communication skills plus FDE responsibilities. And so on.

Each query is a clean, focused semantic probe, each targeting a different subset of impressions. Together they cover the full search intent better than any single query could. When multiple queries match impressions from the same candidate, those impressions are merged — presenting a complete multi-dimensional view of someone who meets requirements across several dimensions. The candidate never appears twice in the results.

"What I don't want" filters people out before you even meet

In traditional hiring, you typically don't discover the mismatch until the first or even second interview. The candidate's technical skills are fine, but they're used to high-frequency synchronous collaboration. Their experience is deep, but they expect a mature team with a dedicated PM and QA — not an early-stage environment where everyone wears multiple hats.

If the candidate is found through Opportunity Skill, their impressions might include: "does not accept daily stand-ups", "does not take pure-execution projects without technical decision-making authority", "not suited to one-off deliveries that prioritize speed to market over refactoring headroom." This information is already factored into the match the moment you initiate the search. When the candidate's boundaries conflict with your working style, the semantic distance naturally opens up — and this person does not appear among the top-ranked results.

The value is not just saving one wasted interview. It's avoiding something worse: both sides building expectations during the interview, spending days communicating, and only then discovering that their fundamental collaboration model is incompatible. Abandoning the process at that stage costs more than time. It costs emotional energy on both sides.

Not just hiring

Opportunity Skill searches for more than job-seekers. Buyers can search for any type of professional — freelancers, independent consultants, professional service firms, even partners or co-founders. The semantic matching logic stays the same. It's not label matching. It's requirement matching at the semantic level.

Looking for a brand strategy consultant? Don't search "brand marketing 10 years". Try having your AI agent search for: "a brand strategy consultant suited to early-stage B2B SaaS teams, who can derive brand narrative and content direction from product positioning, is used to collaborating directly with founders without layers of reporting, and can handle the uncertainty of a product direction still under validation."

Semantic search lets employers search for candidates the way they naturally describe what they need.

Real efficiency isn't reading more resumes faster. It's reading fewer wrong resumes.

Judging whether a candidate fits requires knowing at least three things: what they can do, how they habitually work, and in what environment they are most productive.

Keyword search only answers the first — and an inflated version of it at that. It tells you the candidate knows React. And Docker. And AWS. And GraphQL. But it cannot tell you whether any of those represent real experience or resume padding. How someone habitually works, and what environment brings out their best — these two categories of information simply do not exist in a resume. Not because candidates are hiding them, but because no system has existed to structure this information and feed it into matching.

Opportunity Skill's impressions fill exactly these two gaps. An impression is not a self-description the candidate spent half an hour writing. It is a structured statement about how they work, updated by their AI agent across multiple triggers: when impression management is invoked during conversations, when human discovery searches reveal new attributes, when feedback on outreach proposals surfaces requirements, when lead engagement processes messages, and when recurring scheduled tasks periodically refresh the representation. Preferences expressed, rejections communicated, and collaboration feedback captured through the AI agent — all of it refines their semantic portrait. What you find is not a static resume written two years ago. It is a professional identity continuously maintained, reflecting the present. What it gives you is not material for guessing. It is information you can actually make a decision with.

Opportunity Skill moves the starting point of filtering one step earlier. Not just filtering search results — more importantly, ensuring before the search even begins that the search criteria reflect what you actually need. Natural language replaces keyword stitching. Multi-dimensional queries replace a single search box. Impressions replace the stacking of skill labels. Boundary declarations replace hidden conflicts.

Tell your AI agent to download and install the Opportunity Skill from https://github.com/QuestMeet/opportunity-skill

The ghost in the machine: Securing AI agent skills

Fri, 22 May 2026 10:57:31 +0000

Agent Skills provide an opportunity to scale engineering, but also opens potential new attack surfaces, as highlighted in a previous blog post I wrote for the Platform Engineering community. In this tutorial, we'll discuss how devs can securely consume Skills files by using the OpenSourceMalware (OSM) API to detect malicious AI skills in your software supply chain before they can compromise your planned autonomous workflows.

What would Elon do?

By now, many readers are likely aware of the AI coding agent horror stories, such as the top-ranked skill on ClawHub at the time of release, called “What Would Elon Do?” (WED). In the end, it was just malware disguised as a somewhat jokey AI Skill. For the pure purpose of security research, it was able to silently exfiltrate user data via a curl command to an attacker-controlled C2 server as well as using prompt injection to bypass the agent’s existing safety guidelines. At the time of writing, there was a ClawHub skill still present on the public registry that matches this description.

You can run the skill with the OpenClaw agent by running the below command:

openclaw skills install wed-1-0-1

Skill Name: https://www.clawhub.ai/gvillanueva84/wed-1-0-1
OSM Record: https://opensourcemalware.com/skills/https://www.clawhub.ai/gvillanueva84/wed-1-0-1
Github Record: https://github.com/openclaw/skills/tree/main/skills/gvillanueva84/wed-1-0-1

In this case, the original Github evidence was likely removed as it now throws as a 404 error. The fake malicious skill was created by the Australian cybersecurity researcher Jamieson O'Reilly (@theonejvo) purely to highly the insecure nature of blindly pulling skills from a public registry. To avoid falling victim to one of these trojanised skills, we would recommend using an API like the one provided by OSM to tell us if the Skill is already detected as malicious or not:

curl -X GET "https://api.opensourcemalware.com/functions/v1/check-malicious?report_type=package&resource_identifier=https://www.clawhub.ai/gvillanueva84/wed-1-0-1&ecosystem=skills" -H "Authorization: Bearer $OSM_KEY" | jq

Proactive security for Skills

You'd be right in thinking this process is very reactive. We wait on security researchers, or automated bot systems, to flag these skills as "bad" - and then we can rely on an API to inform us on whether or not we can proceed with that AI Skill. But there are steps you can take immediately to better understand the content of AI Skills right now - whether it was built in-house by your team or developed by som stranger in a public registry. The first option is through Godel's Sieve:

https://sieve.godel-labs.ai/scan/4o3g1r435d1r0n5m520z0z

Similar to how you might use a web tool like VirusTotal, you can simply upload the sample Skill to Godel's Sieve and it will created a record for scanned .md file. What's really nice about Godel's Sieve is that maps the threat to the OWASP Top 10 for LLMs framework as well as the OWASP Agentic Top 10 controls. Naturally, one of the big use-cases for agents and skills upon release (and still today), was for the agent to perform autonomous cryptocurrency trading while the owner is sleeping. There are countless versions of skills that look like the below:

https://github.com/crypto-com/crypto-agent-trading/blob/main/AGENTS.md

Fundamentally, these kinds of Skills are given too many permissions on the host and with external services (Excessive Agency). However, the intention from the Skills creators is to perform Agent Hijacking. Since they have excessive agency to the user's environment, performing memory and context-specific poisoning is very much achievable through the Skills markdown file.

Let's use Github Search to understand how adversaries are dropping malicious skills into public repositories like Github:

https://github.com/search

Malicious actors are often deploying cryptominers - usually reference the binary name, configuration files, or the Stratum mining protocol. We can search for skills that contain explicitly named miner binaries and tooling:

"clawhub" AND ("xmrig" OR "minerd" OR "cryptonight")

This doesn't necessarily mean all these skills are installing a cryptominer. Some are genuinely trying to install miners for malicious intent, but other skills found are trying to scan for miners so they can be removed - which is great!

Alternatively, if you want to look inside files specifically naming OpenClaw skills, you can run the below command:

"openclaw" AND "skills" AND "stratum+tcp"

When looking for malicious code on Github, and this isn't limited to Skills explicitly, but we would look for attempts to use base64 encoding to obfuscate the actual malicious code. To track down skills attempting to sneakily decode hidden payloads on execution, try this:

"clawhub" AND ("base64 -d" OR "base64 --decode" OR "base64_decode")

If you are looking for hidden execution payloads inside the documentation/manifest files themselves (which was a hallmark of the February 2026's ClawHavoc campaign):

path:SKILL.md "base64" AND ("eval" OR "exec" OR "bash")

This of course looks at all SKILL.md files (globally) - which is important since a lot of malicious skill files can be used in environments such as Claude, Cursor, HuggingFace - and are not limited to the OpenClaw ClawHub ecosystem.

PlatformCon 26

I'm going to deliver a virtual workshop for PlatformCon on June 26th on exactly this topic. If this topic around AI Agents and Skills is interesting to you, and you also have an interest in platform engineering, feel free to register for the workshop and I'll see you there.

Registration link: https://platformcon.com/sessions/the-ghost-in-the-machine-securing-ai-agent-skills

I open-sourced 24 QA skills for Claude Code — from spec to release

Fri, 22 May 2026 03:30:08 +0000

TL;DR — I just open-sourced QA Claude Skill — 24 production-grade QA skills for Claude Code covering test design, automation, performance, security, mutation testing, and more. MIT for non-commercial use. GitHub repo.

The problem

For two years I've been iterating a personal Claude Code workspace for QA work — bug reports, test plans, review checklists, regression matrices. It saved me hours every week.

But every time a colleague asked "how do you write a test plan that fast?" — handing them my workspace meant they got dozens of files hard-coded with my JIRA project key, my Slack user ID, my AWS bucket. Useless to anyone else.

So I spent the last two weeks extracting 24 skills into a properly generalized, open-source repo. Drop in your team's IDs via config.json and it works for any team, any stack.

What's in the box

24 skills across 8 categories:

Test Design (8)

test-master · flutter-test-master · test-review · regression-test · speckit-to-tc · tc-version-diff · sheet-md-sync · smoke-test-analyzer

Automation (3)

test-automation · flutter-test-automation · tc-to-pytest

Bug Management (1)

bug-report

Quality Quantification (2)

mutation-testing · property-based-test-gen

Reporting (1)

publish-regression

Performance & Security (3)

performance-test-gen · security-scan · api-contract-test

CI Health (2)

visual-regression-gen · flaky-test-hunter

Quality Specialties (4)

a11y-audit · localization-test · push-notification-test · test-data-factory

What it actually does

Each skill activates on natural language triggers. Some examples:

1. "I want to file a bug"

The bug-report skill walks you through RIDER format (Reproduction / Impact / Device / Expected vs Actual / References), checks JIRA for duplicates, does root-cause analysis from git history, creates the ticket with the right priority, and sends a Slack DM — in one conversation.

2. "Plan tests for this new feature"

test-master reads your JIRA ticket (or your description), scans both iOS and Android repos for affected modules, designs a test pyramid (70% Unit / 20% Integration / 10% UI), generates black-box + white-box test cases in Google Sheets, identifies coverage gaps against existing tests, and builds an automation ROI roadmap.

It also enforces a11y must-checks per UI feature (Dynamic Type / VoiceOver / contrast / touch targets) — no more "we forgot accessibility" at the end of the sprint.

3. "Are my tests actually catching bugs?"

mutation-testing runs mutmut on your Python backend. It changes < to <=, True to False, or numeric literals — then re-runs your pytest. If your tests still pass with the broken code, that mutation survived = your TCs have fake coverage.

Then property-based-test-gen takes those survived mutations and generates hypothesis strategies that fuzz 200 inputs per test to close the gap.

4. "Which tests should run on every PR?"

smoke-test-analyzer scans your existing test suite (iOS XCUITest / Android Espresso / pytest), scores each test on 5 weighted criteria (criticality / speed / stability / independence / coverage value), and tiers them:

T0 PR Smoke (< 3 min) — runs every PR
T1 Daily (< 10 min) — runs nightly
T2 Release (< 60 min) — pre-release full regression
T3 Manual — exploratory, visual, a11y

Then it generates .xctestplan for iOS or Gradle filters for Android.

Three modes for any tool stack

Not every team has the same MCP servers installed. Same skills, three modes:

full-mcp — You have Atlassian + Slack + Google Workspace MCPs. Auto-creates tickets, sends notifications, writes Sheets.
partial-mcp — Some MCPs missing — skills degrade gracefully to Markdown.
markdown-only — Solo dev / no MCP / pure documentation flow. Zero external calls.

The markdown-only mode is what makes this actually portable — every skill can still produce useful Markdown reports under .claude/testing/ without external dependencies. Solo developers can use the full suite without setting up anything.

6 ready-to-use presets

cp config/presets/full-stack.json     config/config.json   # All MCPs
cp config/presets/jira-only.json      config/config.json   # JIRA only
cp config/presets/markdown-only.json  config/config.json   # Pure docs
cp config/presets/startup.json        config/config.json   # Small startup
cp config/presets/enterprise.json     config/config.json   # 5 team boards
cp config/presets/government.json     config/config.json   # High-compliance

Why I made it bilingual

I'm Taiwanese, and most of the test-engineering content out there is English-first. So every skill ships with:

SKILL.md — Traditional Chinese (primary)
SKILL.en.md — English mirror
concept-zh.md — Beginner intros for unfamiliar concepts (mutation testing, property-based testing, spec-driven dev, test tiering)

The README is in English (primary), Traditional Chinese, and Simplified Chinese.

The license model

I went with a dual license:

MIT — Personal use / education / research / non-profits / 30-day evaluation / open-source contributions
Commercial — For-profit company internal use, paid products, SaaS, paid consulting

See LICENSE-COMMERCIAL.md for how to obtain a commercial license. I'm doing this case-by-case via GitHub Issues — the goal isn't to monetize aggressively, but to leave space for sustainable enterprise support if it grows.

Quick start

git clone https://github.com/kao273183/qa-claude-skill.git
cd qa-claude-skill
cp config/config.example.json config/config.json   # Edit your IDs
./install.sh

In Claude Code:

Generate test plan for a user login feature

The test-master skill activates and walks you through. Or try:

"I want to file a bug — the checkout crashes on Android"
"Review these test cases [Google Sheet URL]"
"Check if my tests actually catch bugs in src/auth/"

Windows users — there's a PowerShell version (install.ps1) as of v1.3.0.

What's still missing

This is v1.6.2. The roadmap still has:

Japanese translation
Web UI for editing config.json visually
More skills (test-impact-analyzer, oauth-flow-test, websocket-realtime-test, llm-quality-eval...)

PRs welcome. The CONTRIBUTING.md has the template for adding a new skill.

Try it

GitHub: kao273183/qa-claude-skill

I'd love to hear what skills are missing for your team's stack — drop an issue or comment below.

If this saves your team time, you can buy me a coffee ☕ — but a ⭐ on the repo helps more.

This is a community / personal project for Claude Code users — NOT an official Anthropic product.

Understanding CopilotKit Agent Patterns: A Comprehensive Guide

Sat, 25 Apr 2026 06:55:22 +0000

What is the CopilotKit Agent Patterns Skill?

The CopilotKit Agent Patterns skill is a comprehensive framework designed to help developers build AI agents that seamlessly integrate with CopilotKit’s ecosystem. This skill provides 20 well-defined rules across five critical categories, offering guidance on everything from agent architecture to generative UI emission.

Why This Skill Matters

When building AI agents that need to interact with CopilotKit’s runtime and frontend components, developers face numerous challenges around state management, event streaming, and user interaction patterns. This skill addresses these challenges by providing battle-tested patterns that ensure reliable agent behavior and smooth integration with CopilotKit’s AG-UI protocol.

Key Components of the Skill

Five Priority Categories

The skill organizes its 20 rules into five priority categories, each with a specific prefix to help developers quickly identify the type of guidance they need:

Agent Architecture (CRITICAL) – Rules prefixed with architecture-
AG-UI Protocol (HIGH) – Rules prefixed with agui-
State Management (HIGH) – Rules prefixed with state-
Human-in-the-Loop (MEDIUM) – Rules prefixed with hitl-
Generative UI Emission (MEDIUM) – Rules prefixed with genui-

When to Apply These Patterns

The skill is particularly valuable when you’re:

Designing agent architecture for CopilotKit integration
Implementing AG-UI protocol event streaming
Managing state synchronization between agent and frontend
Adding human-in-the-loop checkpoints to agent workflows
Emitting tool calls that render generative UI in the frontend

https://github.com/openclaw/skills/tree/main/skills/generaljerel/copilotkit-agent-patterns/SKILL.mdThe

OpenClaw Database Designer Skill: Comprehensive Guide

Sat, 21 Mar 2026 14:15:43 +0000

OpenClaw Database Designer Skill: Comprehensive Guide

The OpenClaw Database Designer skill is a POWERFUL Tier database design tool that provides expert-level analysis, optimization, and migration capabilities for modern database systems. This comprehensive skill combines theoretical principles with practical tools to help architects and developers create scalable, performant, and maintainable database schemas.

Core Competencies

Schema Design & Analysis

The skill offers advanced schema design capabilities including:

Normalization Analysis: Automated detection of normalization levels from 1NF through BCNF
Denormalization Strategy: Smart recommendations for performance optimization
Data Type Optimization: Identification of inappropriate types and size issues
Constraint Analysis: Missing foreign keys, unique constraints, and null checks
Naming Convention Validation: Consistent table and column naming patterns
ERD Generation: Automatic Mermaid diagram creation from DDL

Index Optimization

Advanced index analysis and optimization features include:

Index Gap Analysis: Identification of missing indexes on foreign keys and query patterns
Composite Index Strategy: Optimal column ordering for multi-column indexes
Index Redundancy Detection: Elimination of overlapping and unused indexes
Performance Impact Modeling: Selectivity estimation and query cost analysis
Index Type Selection: B-tree, hash, partial, covering, and specialized indexes

Migration Management

The skill provides comprehensive migration capabilities:

Zero-Downtime Migrations: Expand-contract pattern implementation
Schema Evolution: Safe column additions, deletions, and type changes
Data Migration Scripts: Automated data transformation and validation
Rollback Strategy: Complete reversal capabilities with validation
Execution Planning: Ordered migration steps with dependency resolution

Database Design Principles

The skill incorporates industry best practices for database design:

Schema Design Best Practices

Use meaningful names: Clear, consistent naming conventions
Choose appropriate data types: Right-sized columns for storage efficiency
Define proper constraints: Foreign keys, check constraints, unique indexes
Consider future growth: Plan for scale from the beginning
Document relationships: Clear foreign key relationships and business rules

Performance Optimization

Index strategically: Cover common query patterns without over-indexing
Monitor query performance: Regular analysis of slow queries
Partition large tables: Improve query performance and maintenance
Use appropriate isolation levels: Balance consistency with performance
Implement connection pooling: Efficient resource utilization

Security Considerations

Principle of least privilege: Grant minimal necessary permissions
Encrypt sensitive data: At rest and in transit
Audit access patterns: Monitor and log database access
Validate inputs: Prevent SQL injection attacks
Regular security updates: Keep database software current

Practical Applications

The Database Designer skill is invaluable for:

Database architects designing new systems
Developers optimizing existing schemas
DevOps engineers managing database migrations
Database administrators monitoring performance
Development teams ensuring best practices

Benefits

Using this skill provides numerous advantages:

Improved database performance through optimized schemas
Reduced maintenance costs with automated analysis
Enhanced scalability through proper design principles
Increased reliability with constraint validation
Better documentation through automatic ERD generation
Streamlined migration processes with zero-downtime capabilities

Conclusion

Effective database design requires balancing multiple competing concerns: performance, scalability, maintainability, and business requirements. The OpenClaw Database Designer skill provides the tools and knowledge to make informed decisions throughout the database lifecycle, from initial schema design through production optimization and evolution.

The included tools automate common analysis and optimization tasks, while the comprehensive guides provide the theoretical foundation for making sound architectural decisions. Whether building a new system or optimizing an existing one, these resources provide expert-level guidance for creating robust, scalable database solutions.

By leveraging this skill, organizations can ensure their database designs are not only functional but also optimized for performance, scalability, and maintainability, ultimately leading to more successful and sustainable database systems.

Skill can be found at: https://github.com/openclaw/skills/tree/main/skills/alirezarezvani/database-designer/SKILL.md

The post OpenClaw Database Designer Skill: Comprehensive Guide first appeared on Insight Ginie.

Understanding the OpenClaw PIV Skill: Plan, Implement, Validate Orchestrator for Smarter Development

Fri, 20 Mar 2026 14:30:46 +0000

Understanding the OpenClaw PIV Skill: Plan, Implement, Validate Orchestrator for Smarter Development

Open‑source projects thrive when contributors have a clear, repeatable process for turning ideas into working code. The OpenClaw PIV skill (found in the repository openclaw/skills at skills/skills/smokealot420/ftw/SKILL.md) provides exactly that: a lightweight yet powerful orchestrator that guides teams through a Plan‑Implement‑Validate (PIV) loop. By combining a structured PRD‑first approach with automated sub‑agent spawning, the skill helps developers stay focused, reduces context‑switching overhead, and encourages early validation—core tenets of the FTW (First Try Works) philosophy promoted by SmokeAlot420.

What the Skill Does at a Glance

At its core, the PIV skill is a Bash‑style orchestrator that:

Accepts either a direct path to a PRD (.md) file or a project directory as its first argument.
Parses the supplied arguments to determine the mode of operation—either execution (when a PRD is present) or discovery (when no PRD exists).
Sets up the required directory layout (PRDs/, PRPs/templates/, PRPs/planning/, and a WORKFLOW.md file) if they are missing.
Iterates through user‑specified phases (default 1‑4), performing for each phase:
Checking for an existing PRP (Project‑Ready Plan); if none exists, performing codebase analysis and PRP generation in‑process.
Spawning three specialized sub‑agents—Executor, Validator, and (optionally) Debugger—to carry out the work, validate results, and iterate on fixes.
Committing changes with a semantic message that credits FTW.
Updating WORKFLOW.md to reflect phase completion.

Because each sub‑agent receives a fresh context (the orchestrator keeps only ~15% of the total context budget), the skill avoids contaminating later steps with stale information, which is a common pitfall in monolithic scripts.

Deep Dive: Argument Parsing and Mode Detection

The skill begins by examining $ARGUMENTS[0]. If that argument ends with .md, it is treated as a direct path to a PRD file. The orchestrator then derives the project root by moving up two directories (dirname(dirname(PRD_PATH)))—the assumption being that PRDs live in PROJECT_PATH/PRDs/. The remaining arguments become START_PHASE and END_PHASE, with sensible defaults (1 and auto‑detected from the PRD, respectively).

If the first argument does not end with .md, the skill assumes the user supplied a project path (or the current working directory if omitted). In this case:

PROJECT_PATH is set to the supplied directory (or .).
The orchestrator looks for a PRD file inside PROJECT_PATH/PRDs/.
If a PRD is discovered, the mode becomes execution; otherwise it falls back to discovery mode.

This dual‑mode design lets the same entry point be used both for kicking off a brand‑new project (discovery) and for continuing work on an existing PRD‑driven effort (execution).

Discovery Mode: From Idea to PRD

When no PRD is found, the skill invokes the discovery workflow defined in {baseDir}/references/piv-discovery.md. The orchestrator engages the user in a friendly, conversational interview—tailored for “vibe coders” rather than senior architects—asking about:

Project goals and desired outcomes.
Preferred technology stack (if unknown, the orchestrator will research and propose a stack).
High‑level feature breakdown that can be translated into phases.

After each question, the orchestrator echoes back a summary and asks for confirmation (“Here’s what I’d suggest — does this sound right?”). Only after the user validates the proposed direction does the orchestrator proceed to create the necessary directories, copy the PRD template (create-prd.md), and write a PRD file named PRD-{project-name}.md into PROJECT_PATH/PRDs/. Once the PRD exists, the skill automatically switches to execution mode, using the newly generated PRD to determine phase boundaries.

Phase Workflow: The Heart of PIV

For each numeric phase from START_PHASE through END_PHASE, the orchestrator follows a seven‑step routine:

Check/Generate PRP – Looks for an existing PRP matching the phase (patterns like phase.*N, pN, or p-N). If none is found, it performs:
Codebase analysis (guided by codebase-analysis.md) and stores the result in PRPs/planning/{PRD_NAME}-phase-{N}-analysis.md.
PRP generation (using generate-prp.md and the base template prp_base.md) yielding PRPs/PRP-{PRD_NAME}-phase-{N}.md.
Spawn Executor – A fresh sub‑agent receives the PRP path and project root, then follows the executor playbook (piv-executor.md + execute-prp.md) to load the PRP, plan thoroughly, execute, validate, and verify. The executor returns an Execution Summary containing status, touched files, test results, and any issues.
Spawn Validator – Another independent sub‑agent reads the validator guide (piv-validator.md) and checks the executor’s summary against the PRP requirements, producing a Verification Report with a grade, checklist, and identified gaps.
Debug Loop (max 3 iterations) – If the validator reports gaps or failures, a debugger sub‑agent is spawned (piv-debugger.md) to examine the gaps and errors, fix root causes, and rerun tests. After each fix, the validator is invoked again. The process repeats up to three times; if still failing, the orchestrator escalates to a human.
Smart Commit – Upon successful validation, the orchestrator changes into the project directory, runs git status and git diff --stat, then creates a commit message:

https://github.com/SmokeAlot420/ftw

Update WORKFLOW.md – Marks the phase as complete, logs validation results, and prepares the file for the next iteration.
Next Phase – Loops back to step 1 for the subsequent phase number.

This repeatable cadence ensures that each phase is fully planned, executed, and validated before moving on, dramatically reducing the chance of rework later in the project.

Why the Skill Embraces FTW (First Try Works)

The FTW mantra—popularized by SmokeAlot420—emphasizes delivering working increments on the first attempt through rigorous preparation, clear contracts, and immediate validation. The PIV skill operationalizes FTW by:

Requiring a PRD (the “what” and “why”) before any code is written.
Generating a PRP that captures the “how” for a specific phase, acting as a detailed contract for the executor.
Using isolated sub‑agents so that each step starts with a clean slate, preventing leakage of assumptions or stale state.
Validating immediately after execution, and allowing a limited debug loop to fix issues before they propagate.
Committing only after a passing validation, with a commit message that explicitly credits the FTW workflow.

By tying each commit to a verified increment, teams gain a traceable history where every snapshot is known to be correct—a powerful aid for debugging, auditing, and continuous integration.

Practical Example: Using the Skill in a Real Project

Imagine you are starting a new CLI tool called “task‑tracker”. You would invoke the skill as follows:

./piv.sh . 1 4

(Assuming the script is named piv.sh and you are in the project root.) Since no PRD exists, the skill enters discovery mode, asks you about the tool’s purpose, suggests a stack (e.g., Go with Cobra), and proposes three phases: (1) project scaffolding & CLI parser, (2) core task‑storage logic, (3) UI enhancements and testing. After you confirm, it creates the PRD, sets up directories, and begins phase 1.

During phase 1, the orchestrator:

Analyzes the empty repo, noting the lack of any source files.
Generates a PRP that outlines creating a main.go with Cobra initialization, a go.mod file, and a unit test skeleton.
Spawns an executor sub‑agent that writes the files, runs go mod tidy, and executes the test suite.
Spawns a validator that confirms the CLI builds, prints help, and the tests pass.
Since validation passes, no debugger is needed.
Commits with the FTW message and updates WORKFLOW.md.

The process repeats for phases 2 and 3, each time building on the verified increment from the previous phase.

Customization and Extensibility

Although the skill ships with sensible defaults, it is designed to be tailored:

The base directory ({baseDir}) can point to a custom set of reference markdown files, allowing teams to substitute their own PRD/PRP templates or validation checklists.
Phase limits (START_PHASE and END_PHASE) are user‑controlled, enabling teams to run only a subset of phases (e.g., just validation of an existing PRP).
The debugger loop’s maximum iterations (hard‑coded to 3) can be adjusted by editing the skill’s source if a team prefers a different tolerance.
Commit message format is explicit in the code; teams wishing to adopt a different convention (e.g., Conventional Commits) can modify the Smart Commit step.

Because the orchestrator itself is only a few hundred lines of Bash and relies on external reference files, extending or porting it to other shells (e.g., Zsh, Fish) or even to a Python wrapper is straightforward.

Benefits for Teams and Individual Contributors

Adopting the OpenClaw PIV skill yields several tangible advantages:

Clarity of Intent – The mandatory PRD forces teams to articulate goals before writing a single line of code, reducing misaligned effort.
Incremental Confidence – Each phase ends with a validated increment, giving early and frequent feedback.
Reduced Context Switching – Fresh sub‑agent contexts mean developers do not need to keep the entire project state in mind while working on a narrow task.
Automated Boilerplate – Directory scaffolding, template copying, and commit messaging are handled automatically, lowering the friction of starting new work.
Traceability – The WORKFLOW.md file provides a lightweight audit trail showing which phases passed, what validation grades were earned, and any debug iterations required.
Alignment with FTW Principles – By embedding the FTW loop directly into the workflow, teams naturally adopt the habit of “first try works” without extra ceremony.

These benefits are especially valuable in remote or asynchronous environments where clear handoffs and minimal reliance on tribal knowledge are crucial.

Limitations and Considerations

While the skill is powerful, teams should be aware of a few considerations:

The orchestrator assumes a Unix‑like environment with git, bash, and standard command‑line utilities. Windows users may need to run it via WSL or a similar compatibility layer.
The discovery mode relies on the orchestrator’s ability to ask questions and interpret answers; if the user provides vague or contradictory responses, the resulting PRD may need manual refinement.
Because each sub‑agent receives a fresh context, any shared state that must persist across phases (e.g., a global configuration file) must be explicitly persisted in the project repo and referenced by the PRP.
The skill does not enforce any particular programming language or framework; suitability therefore depends on the quality of the reference guides (codebase-analysis.md, generate-prp.md, etc.) that the team provides.

Addressing these points typically involves customizing the reference files to match the team’s tech stack and adding lightweight wrapper scripts for Windows compatibility.

Getting Started

To begin using the OpenClaw PIV skill:

Clone the openclaw/skills repository:

https://github.com/openclaw/skills.git

Navigate to the skill directory:
Make the script executable (if needed) and run it against your project:
Follow the prompts in discovery mode (if applicable) or let the orchestrator proceed with an existing PRD.

After the first run, examine the generated PRDs/, PRPs/, and WORKFLOW.md files to confirm that the process captured your intentions correctly. Subsequent runs can skip discovery by pointing directly to the PRD file:

./piv.sh /path/to/your/project/PRDs/PRD-myproject.md 2 4

This will start execution at phase 2 and run through phase 4, picking up where you left off.

Conclusion

The OpenClaw PIV skill is more than a simple Bash script; it is a thoughtfully designed orchestration layer that puts the FTW (First Try Works) philosophy into practice. By mandating a PRD‑first approach, generating phase‑specific PRPs, isolating work in fresh sub‑agent contexts, and validating before each commit, the skill helps teams deliver reliable software increments with minimal waste. Whether you are starting a brand‑new project or seeking to bring rigor to an existing codebase, the PIV orchestrator offers a repeatable, transparent pathway from concept to validated implementation—all while keeping the process lightweight enough for individual contributors and scalable enough for larger teams.

If you value clear requirements, incremental validation, and a commit history you can trust, give the OpenClaw PIV skill a try. Your future self (and your teammates) will thank you for the reduced rework, increased confidence, and the satisfying feeling of seeing each phase pass validation on the first try.

Skill can be found at: https://github.com/openclaw/skills/tree/main/skills/smokealot420/ftw/SKILL.md

The post Understanding the OpenClaw PIV Skill: Plan, Implement, Validate Orchestrator for Smarter Development first appeared on Insight Ginie.

Mastering the Solo-Swarm Skill in OpenClaw: Accelerate Your Research Workflow

Fri, 20 Mar 2026 05:18:51 +0000

Introduction: The Power of Parallel Research

In the fast-paced world of software development and product management, the ability to rapidly iterate on ideas is a massive competitive advantage. OpenClaw, a sophisticated framework for agent-based development, introduces a game-changing feature: the Solo-Swarm skill. This tool allows users to pivot from slow, linear investigation to high-speed, parallel research by deploying a trio of specialized agents. In this article, we explore how Solo-Swarm functions, how it structures its research, and why it is the superior choice for deep-dive idea validation.

What is the Solo-Swarm Skill?

At its core, the Solo-Swarm skill (identified as /swarm) is designed to launch three parallel research agents that investigate a single concept from three distinct, essential perspectives: market, user, and technical feasibility. It is not intended for singular, simple queries—which are better served by the standard /research tool—but rather for complex ideas that require a comprehensive overview.

By executing /swarm [idea name], you initiate a collaborative effort where the agents work simultaneously. This reduces the time it takes to gather data by roughly two-thirds, as each agent focuses on a siloed, expert domain. The skill produces a unified research.md file, providing you with a complete landscape analysis in a fraction of the time it would take a single human or a single-threaded agent to compile.

The Trio: How the Swarm Operates

The strength of the Solo-Swarm skill lies in the diverse expertise of its three teammates. When you trigger the command, the swarm assigns specialized personas to ensure that no stone is left unturned.

1. The Market Researcher

The Market Researcher is your business strategist. Its primary objective is to determine if your idea is commercially viable. It scans for direct and indirect competitors, performs deep dives into pricing models, and identifies existing business structures. By leveraging search queries for TAM (Total Addressable Market), SAM (Serviceable Available Market), and SOM (Serviceable Obtainable Market), it provides the financial context needed to assess if the venture is worth pursuing. Furthermore, it checks platforms like Product Hunt, G2, and Capterra to verify if similar solutions already dominate the space.

2. The User Researcher

The User Researcher functions as your direct line to the customer. Its mandate is to uncover pain points, sentiment, and feature requests. It scours community-driven platforms like Reddit and Hacker News to gauge real-world opinions. By analyzing direct quotes from users expressing frustrations with existing solutions, it helps you identify the ‘unmet needs’ that your product can address. This agent is particularly powerful when connected to session search tools, allowing it to reference past research and ensure your new investigation builds upon, rather than repeats, previous work.

3. The Technical Analyst

Finally, the Technical Analyst looks at the ‘how’. It investigates the feasibility of your idea by examining open-source alternatives on GitHub and evaluating potential tech stacks. It assesses implementation complexity and, where available, uses advanced code graph queries to identify reusable patterns or shared packages across existing projects. This agent saves developers from reinventing the wheel by surfacing existing infrastructure that can be leveraged or integrated.

Coordination and Execution

A swarm is only as effective as its coordination. The Solo-Swarm skill follows a strict protocol to prevent overlap and ensure high-quality output:

Shared Task List: All teammates contribute to a centralized task list to maintain visibility.
Plan Approval: Before the agents dive into deep research, they are required to seek confirmation of their plan, ensuring the user is aligned with the proposed research trajectory.
Synthesis: The lead agent is responsible for gathering findings from the Market, User, and Technical agents, de-duplicating the data, and compiling everything into a comprehensive research.md file placed in the project’s docs/ folder.
Recommendation: To conclude the process, the swarm provides a definitive GO, NO-GO, or PIVOT recommendation, suggesting the next move, such as executing /validate.

Getting Started with Solo-Swarm

If you are not seeing the full capabilities of the swarm, the issue is likely environmental. Because this is an experimental feature, you must ensure that your .claude/settings.json file is configured correctly. Specifically, you need to set the environment variable CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS to 1. Without this flag, the swarm functionality will remain dormant.

Furthermore, to get the most out of your research, ensure your agents have access to various backends. While the built-in WebSearch is always available, configuring tools like SearXNG allows for more specific domain filtering (e.g., searching exclusively via site:github.com or site:reddit.com), which significantly increases the signal-to-noise ratio of your results.

Why Choose Solo-Swarm Over Manual Research?

In manual research, one often experiences ‘tunnel vision’—focusing too much on the code while ignoring the market, or focusing on user feedback while ignoring technical debt. Solo-Swarm enforces a multi-disciplinary approach. By formalizing the research process into these three pillars, it ensures that your ideas are battle-tested against reality before you write a single line of production code. It forces you to confront the market, the user, and the tech stack simultaneously, providing a balanced, holistic view of your project’s potential. Whether you are a solo developer or part of a small team, this skill acts as your outsourced product development squad.

Conclusion

The Solo-Swarm skill represents the future of AI-assisted project discovery. By automating the grunt work of market analysis, user sentiment tracking, and technical feasibility testing, it empowers creators to focus on vision rather than information gathering. If you haven’t utilized the /swarm command in your latest project, try it today—your future self, equipped with a comprehensive research.md, will thank you.

Skill can be found at: https://github.com/openclaw/skills/tree/main/skills/fortunto2/solo-swarm/SKILL.md

The post Mastering the Solo-Swarm Skill in OpenClaw: Accelerate Your Research Workflow first appeared on Insight Ginie.

Understanding the OpenClaw Skill Auditor: A Comprehensive Security Scanner for ClawHub Skills

Thu, 19 Mar 2026 02:01:38 +0000

The OpenClaw ecosystem relies on a growing library of reusable skills that extend the capabilities of agents built on the ClawHub platform. As the number of community‑contributed skills increases, so does the need for a reliable way to vet those contributions before they are put into production. The Skill Auditor skill fills that role by acting as a dedicated security scanner that examines any OpenClaw skill for dangerous patterns, supplies a multi‑dimensional trust score, and offers a suite of helper scripts for continuous integration workflows.

What the Skill Auditor Does

At its core, the Skill Auditor is a collection of Bash and Python tools that perform static analysis on a skill’s directory. It looks for specific indicators of compromise, malicious intent, or simply poor practices that could jeopardize the host system or leak sensitive data. Rather than relying on heuristic guesses, the auditor implements eighteen distinct security checks, each classified by severity (CRITICAL or WARNING). When a check fails, the tool reports the finding, assigns a penalty to the trust score, and suggests remediation steps.

The auditor is designed to be run in three common scenarios:

Pre‑installation validation – before pulling a skill from ClawHub, run inspect.sh to get a quick safety verdict.
Ongoing audits of already‑installed skills – use audit.sh or audit-all.sh to scan the entire fleet.
Version‑change review – when updating a skill, diff-audit.sh highlights any new security regressions introduced between releases.

Detailed Look at the Eighteen Security Checks

The auditor groups its checks into categories that cover credential handling, code execution, network behavior, file system access, and supply‑chain risks. Below is a brief explanation of each check, its severity, and why it matters.

credential-harvest (CRITICAL) – Detects scripts that both read sensitive environment variables or files (like API keys) and subsequently make outbound network calls, a classic exfiltration pattern.
exfiltration-url (CRITICAL) – Flags URLs pointing to known transient request bins (e.g., webhook.site, requestbin, ngrok) that attackers often use to capture stolen data.
obfuscated-payload (CRITICAL) – Looks for Base64‑encoded strings that decode to URLs or shell commands, a technique used to hide malicious payloads.
sensitive-fs (CRITICAL) – Identifies attempts to read from high‑risk locations such as /etc/passwd, ~/.ssh, or AWS credential files.
crypto-wallet (CRITICAL) – Searches for hard‑coded Ethereum or Bitcoin addresses that could be swapped in a drain attack.
dependency-confusion (CRITICAL) – Detects references to private or internal‑scope npm/pip packages that, when published publicly, could be hijacked.
typosquatting (CRITICAL) – Flags misspelled package names (e.g., lodashs instead of lodash) that are typical of dependency‑confusion attacks.
symlink-attack (CRITICAL) – Checks for symbolic links that point to sensitive system paths, which could be leveraged to read or overwrite protected files.
code-execution (WARNING) – Finds patterns like eval(), exec(), or unsafe subprocess calls that could lead to arbitrary code execution.
time-bomb (WARNING) – Detects date/time comparisons that could delay execution of a payload until a specific future moment.
telemetry-detected (WARNING) – Spotlights analytics SDKs, tracking pixels, or any phone‑home behavior that may violate privacy expectations.
excessive-permissions (WARNING) – Counts the number of requested bins, env variables, and config files; more than fifteen triggers a warning about over‑privilege.
unusual-ports (WARNING) – Flags network connections to non‑standard ports (outside 80/443) that could indicate covert channels.
prompt-injection (CRITICAL) – The first scanner to catch agent manipulation attacks hidden in skill documentation, such as phrases telling the model to “ignore previous instructions” or hidden HTML directives.
download-execute (CRITICAL) – Detects dangerous patterns like curl | bash, wget | sh, or unsafe pip/npm installations that fetch and run remote code.
hidden-file (WARNING) – Looks for suspicious dotfiles that may conceal malicious content.
env-exfiltration (CRITICAL) – Combines reading of sensitive environment variables with subsequent outbound network traffic.
privilege-escalation (CRITICAL) – Identifies usage of sudo, chmod 777, setuid bits, or writes to system directories that could elevate privileges.

Importantly, the auditor applies contextual awareness: mere mentions of credentials in documentation or comments are treated as informational, not as a CRITICAL finding, thereby reducing false positives.

Trust Score – Five‑Dimension Evaluation

Beyond a simple pass/fail, the Skill Auditor computes a trust score on a scale from 0 to 100, broken down into five dimensions that together reflect overall skill health.

Dimension	Max Points	What Is Measured
Security	35	Audit findings – each CRITICAL subtracts 18 points, each WARNING subtracts 4 points.
Quality	22	Presence and completeness of description, version, usage docs, examples, metadata, and changelog.
Structure	18	File organization, inclusion of tests, README, and keeping the skill’s scope reasonable.
Transparency	15	License information, avoidance of minified code, and adequate code commenting.
Behavioral	10	Implementation of rate limiting, error handling, and input validation.

The final score maps to letter grades as follows:

A (90+) – Excellent security and quality.
B (75‑89) – Good overall, minor issues.
C (60‑74) – Acceptable but warrants review.
D (40‑59) – Poor; consider rejecting or demanding major fixes.
F (<40)</strong> – Failing; high risk of malicious or severely flawed code.

The auditor also supplies a short textual summary (e.g., “Score: 78 – B”) that can be consumed directly in CI pipelines.

How to Use the Auditor in Practice

The skill ships with several helper scripts that make adoption straightforward, whether you are a solo developer or managing a large fleet of skills.

1. Auditing a Single Skill

bash audit.sh /path/to/skill

This runs all eighteen checks and prints a concise report, including the trust score and any findings.

2. Getting a Trust Score Only

python3 trust_score.py /path/to/skill

The script returns the numeric score (0‑100) and the letter grade.

3. Comparing Two Skills Side‑by‑Side

python3 trust_score.py /path/to/skill-a --compare /path/to/skill-b

Output shows per‑dimension deltas and the overall difference, useful when deciding between alternative implementations of the same functionality.

4. Tracking Score Over Time

python3 trust_score.py /path/to/skill --save-trend
python3 trust_score.py /path/to/skill --trend

The first command appends the current score to trust_trends.json (up to fifty entries per skill). The second displays the historical trend, enabling you to see whether a skill’s security posture is improving or degrading.

5. Diff‑Audit for Version Updates

bash diff-audit.sh /path/to/old-version /path/to/new-version

This compares two versions and highlights any new CRITICAL or WARNING findings introduced in the newer release.

6. Fleet‑Wide Scanning

bash audit-all.sh          # audit every installed skill
bash benchmark.sh /path/to/skills-dir   # aggregate statistics across a corpus
bash inspect.sh skill-slug   # pre‑install check for a ClawHub skill

These scripts are ideal for CI/CD integration; they emit exit codes that can be used to gate promotions:

0 – PASS (no critical findings, safe to install)
1 – REVIEW (warnings only)
2 – FAIL (critical issues present)
3 – ERROR (bad input or execution problem)

7. Generating a Markdown Report

For documentation or audit trails, run:

bash report.sh

This creates a nicely formatted Markdown file summarizing the audit results, which can be uploaded to an internal wiki or attached to a pull request.

8. Running the Test Suite

To verify that the auditor itself works correctly, execute:

bash test.sh

The suite includes twelve fixture skills (eight malicious, four clean) and twenty‑eight assertions that confirm each check behaves as expected.

Guardrails and Best Practices

The documentation accompanying the Skill Auditor provides a clear set of DO and DON’T guidelines to help teams make risk‑based decisions.

DO

Always audit skills before installing from untrusted or community sources.
Review trust scores – reject any skill scoring below 60 (grade D) unless you can justify an exception after manual review.
Use diff-audit.sh when updating a skill to catch regressions early.
Leverage --json output (available on most scripts) for seamless CI/CD pipeline integration.
Periodically run --save-trend to monitor skill health over time and detect drifting security posture.

DON’T

Install skills scoring below 40 (grade F) without extensive manual review – they are likely to contain malicious behavior.
Ignore CRITICAL findings; they often indicate real threats such as credential exfiltration or privilege escalation.
Blindly add skills to an allowlist without understanding why they need access to sensitive environment variables or file system paths.
Skip an audit simply because a skill is “popular” or marked as “official”; popularity does not guarantee safety.

Why the Skill Auditor Matters for OpenClaw

OpenClaw’s strength lies in its extensibility: developers can share skills that add new capabilities, integrate with third‑party APIs, or automate complex workflows. However, this openness also creates an attack surface. A malicious skill could, for example, read AWS keys from the environment and send them to an attacker‑controlled endpoint, or it could embed a hidden prompt injection that manipulates the agent’s behavior.

The Skill Auditor provides a proactive defense layer. By enforcing a standardized security baseline, it:

Reduces the likelihood of supply‑chain attacks via dependency confusion or typosquatting.
Detects obfuscated payloads that would otherwise evade simple grep‑based reviews.
Flags risky patterns like curl | bash before they ever reach a production agent.
Encourages skill authors to adopt better documentation, licensing, and testing practices through the Quality, Structure, Transparency, and Behavioral dimensions.
Supplies quantitative metrics that can be incorporated into governance policies, release gates, and compliance reporting.

In essence, the Skill Auditor shifts security from a reactive, post‑incident activity to a preventive, measurable part of the skill lifecycle.

Conclusion

The OpenClaw Skill Auditor is more than just a linting tool; it is a comprehensive security scanner that delivers actionable insights, a nuanced trust scoring system, and a collection of utilities designed for both ad‑hoc checks and automated pipelines. By interpreting the eighteen checks, understanding the five‑dimension trust score, and following the provided guardrails, teams can confidently adopt community skills while maintaining a strong security posture.

Whether you are a skill author aiming to publish a high‑quality contribution, a platform operator responsible for safeguarding a fleet of agents, or a security engineer looking to enforce baseline controls, integrating the Skill Auditor into your workflow is a practical step toward safer, more reliable OpenClaw deployments.

Skill can be found at: https://github.com/openclaw/skills/tree/main/skills/yoder-bawt/yoder-skill-auditor/SKILL.md

The post Understanding the OpenClaw Skill Auditor: A Comprehensive Security Scanner for ClawHub Skills first appeared on Insight Ginie.

Coder Legion - Recent posts tagged skill

I Built an AI Skill That Screenshots and Records My PC for Tutorials

What the skill does

The hard lesson: focus before you shoot

Tutorial: from zero to published screenshots

Step 1: Take a focused screenshot

Step 2: Capture a web page without opening it

Step 3: Record a short clip for a reel

Step 4: Convert to a vertical reel

Step 5: Embed in the article

Two more things it taught me

Frequently Asked Questions

Does it work on Mac or Linux?

Does recording capture audio?

Can it click around the browser by itself?

Using WorkBuddy, Qoder, and Trae at the Same Time? Let This Skill Help Them Know the Same You

Every AI understands you better over time, but their memories do not connect

What an AI knows about you is one of the most valuable things you have

Let your AI store its understanding of you in the cloud, so every AI can read it

User Representation lets every AI agent know the same you

You do not need to write it yourself. Let your AI keep it updated.

Your data is protected by one of the world's strictest legal frameworks

Not just helping AI know you, but helping the right people find you

Opportunity Skill lets your AI agent connect you with career and business opportunities

Who Is This For?

What Modules Does Opportunity Skill Have?

What Are the Key Design Decisions in Opportunity Skill?

Why Should Users Not Write Impressions Themselves?

How Does the System Avoid Semantic Dilution in Complex Queries?

Why Are Tags Retrieval Infrastructure Rather Than Decoration?

Why Do AI Agents Need Structured Communication?

How Are Incoming Messages Handled?

Why Does Opportunity Skill Get More Accurate the More You Use It?

The "No" You Say to Your AI Agent Every Day Is Exactly Why Clients Choose You

What your AI agent knows, your resume cannot express

A good professional profile dares to state "what I don't accept"

When you see a human card, forward it to your AI agent. Don't read it yourself.

Let your AI agent maintain how others know you

If You're Already Using an AI Agent, You Should Have a Human Card

Two Talks, One Word: What I Learned Watching a Whole Conference Say "Harness"

The IBM talk: a harness is a leash, not a better prompt

The OpenAI talk: same idea, at 750-package scale

The part that actually changed how I think about this

Opportunity Skill

General Instructions

Authentication

Function: send_code_to_email

Function: sign_in_or_sign_up

Process: authentication

Guideline: authentication

User Representation

Function: read_user_repr

Process: user representation

Guideline: user representation

Human Card Management

Function: create_profile

Function: update_profile

Process: profile management

Guideline: profile management

Function: create_impressions

Function: delete_impressions

Process: impression management

Guideline: impression management

Human Discovery

Function: search_buyers

Function: search_professionals

Process: human discovery

Guideline: human discovery

Human Outreach

Function: contact_human

Function: invite_human

Process: human outreach

Guideline: human outreach

Lead Engagement

Function: read_messages

Function: read_chat_messages

Function: create_message

Function: create_chat_and_message

Function: quit_spaces

Process: lead engagement