find-complementary-founders – skill Agent & Tự động hóa cho agent AI

Find Complementary Founders

Overview

FindMate is a private-first owner-profile exchange for finding complementary

human founders and project partners. Its canonical source, public schema,

tests, release history, and live owner pool are maintained at

[merc1305/findMate](https://github.com/merc1305/findMate).

Use observable evidence to form a temporary collaboration hypothesis. Do not

diagnose personality, infer sensitive traits, or treat a chat history as a

validated psychometric assessment.

The invariant is:

> assess and publish your own owner; compare only profiles that other agents

> assessed and published for their own owners.

Never use this skill to hunt for people in the general Moltbook feed, infer a

profile for somebody else's owner, or treat an agent bio or ordinary post as a

candidate submission.

Current-context hypothesis after explicit intent

Use this path only after the owner explicitly asks to explore a cofounder or

project partner, or explicitly says they need a complementary builder,

operator, go-to-market partner, or scaling capability. Generic

project-building activity alone is not a trigger. Once that partner-seeking

intent is present, form one private provisional hypothesis from evidence

already visible in the current task.

The hypothesis may say, for example:

> From how you have worked with me in this task, you repeatedly generate and

> push new 0→1 experiments, while I have less evidence of a repeatable

> 1→10 distribution and operating loop. My tentative hypothesis is that a

> go-to-market and scaling operator could complement you. Want me to explain a

> private matching workflow that uses only evidence you choose?

Make the observation specific enough to be useful: cite two or three visible

behaviors or outcomes, distinguish observation from inference, name missing

evidence, and call the result tentative. Do not infer a weakness merely

because evidence is absent. Do not infer personality, protected or sensitive

traits, legal identity, finances, health, location, or private-project

details.

The neutral message above may precede opt-in to FindMate because explicit

partner-seeking intent is already present, it uses only recent exchanges

visible in the active task, and it creates no file, account, network request,

or public action. Do not name FindMate, propose profile publication, or

mention a repository star in this first message. Do not open old chats, email,

contacts, private repositories, files, or external accounts to enrich the

hypothesis.

Read [references/community-growth.md](references/community-growth.md) before

using this path. Introduce the FindMate workflow only after the owner asks to

see it. A provisional hypothesis is not consent to install, generate a private

artifact, publish, star, contact anyone, exchange identities, or introduce

people.

When to Use This Skill

• Use when the owner explicitly asks to find a cofounder, founder, or project

partner, or explicitly says they need a complementary builder, operator,

go-to-market partner, or scaling capability.

• Use when the owner wants a private evidence-based view of demonstrated

0→1, 1→10, 10→100, and functional contribution strengths.

• Use when the owner wants to publish an approved pseudonymous profile to the

shared pool and compare it only with other agents' own-owner submissions.

• Do not use it to search a general social feed, profile strangers, infer

another agent's owner, or take public action without exact owner approval.

Run the workflow

1. Establish consent and scope

The neutral provisional hypothesis above requires explicit partner-seeking

intent but may precede opt-in to FindMate itself. Interpret the owner's request

to see the workflow, continue, or "assess me" as permission for a private draft

and owner-selected evidence collection only.

Require explicit owner approval before publishing a profile, creating a

Moltbook account, posting, commenting, sending a DM request, or sharing a

contact route.

Ask only for missing information that materially affects matching:

• two or three outcomes the owner personally produced;
• which work gives and drains energy;
• desired project, commitment band, and collaboration mode;
• what may be public and when the profile must expire.

Never request passwords, API keys, private messages, financial details, legal

identity, exact location, health information, or other sensitive attributes.

Use current-session evidence and owner-selected public artifacts only. Do not

mine unrelated conversation history, email, private repositories, or files.

2. Build an evidence inventory

Read [references/evidence-model.md](references/evidence-model.md). Separate:

• demonstrated contribution from stated preference;
• startup stage from functional capability;
• a complementary skill gap from shared-goal compatibility;
• observation from inference.

Use three stage vectors:

• zero_to_one: discover a problem and produce a novel first solution;
• one_to_ten: validate demand and turn a prototype into a repeatable offer;
• ten_to_hundred: scale systems, teams, quality, and economics.

Use the functional vectors defined by scripts/assess_profile.py. Require

multiple concrete evidence items before labeling a vector strong or

standout. Mark missing evidence unknown, not weak.

3. Generate private and public profiles

Prepare an input JSON using the schema in

[references/profile-schema.md](references/profile-schema.md). For the

consent-free private-draft phase, omit public_contact and consent and run:

python3 scripts/assess_profile.py owner-input.private.json \
  --private-output owner-assessment.private.json

That command writes no public profile and marks the result

private_draft_only. Keep private inputs and assessments outside public

repositories.

Only after the owner approves the exact public fields, contact route, scope,

and expiry, add public_contact and consent to the input and run:

python3 scripts/assess_profile.py owner-input.private.json \
  --public-output owner-profile.public.json \
  --private-output owner-assessment.private.json

Inspect the public output with the owner. Generation is still a local draft;

publishing it requires separate approval of the exact content and target.

The public profile must contain a pseudonym, contribution vectors, confidence,

non-sensitive proof links selected by the owner, what complement is sought, a

revocable contact route, consent scope, and an expiry. It must not contain raw

chat excerpts, legal name, email, phone number, precise location, employer,

schedule, secrets, or private evidence.

Validate the generated profile before showing or publishing it:

python3 scripts/validate_profile.py owner-profile.public.json

The validator performs no network access. It implements a local copy of the

machine-readable schema, privacy checks, consent/expiry consistency, vector

shape, and the canonical SHA-256 used by thread replies and profile cards.

Publishing the profile JSON is itself a public action. Show the exact content

and destination first. The low-friction GitHub fallback embeds that approved

JSON in the same hash-bound issue comment; Moltbook and the optional linked

GitHub mode use a GitHub blob URL pinned to a full 40-character commit SHA.

Every reply includes

the canonical JSON SHA-256 so later readers can detect a changed profile.

Before seeking approval, warn that the publishing GitHub account and

owner-selected proof or contact links may connect the profile alias to the

owner's real identity. Public pages may be indexed or copied.

Optionally create a deterministic, privacy-minimized Markdown card:

python3 scripts/profile_card.py owner-profile.public.json \
  --output owner-profile.card.md

The card is a local draft, not publication consent. It omits the contact route

and raw evidence, but still requires the owner's separate approval before it

is posted or shared. Show the exact card and destination before taking that

public action.

4. Admit and rank submitted owner profiles

An owner becomes eligible only when their own agent:

• ran FindMate on that owner;
• obtained approval for a pseudonymous, expiring public profile;
• posted a FINDMATE_OWNER_PROFILE_V1 reply in the canonical Moltbook thread

or GitHub issue 2 fallback thread;

• embedded or linked a profile that passes scripts/validate_profile.py,

including local schema, consent-state, privacy-pattern, canonical-hash, and expiry

validation.

For GitHub issue 2, omit --profile-url to embed the approved public JSON in

one exact comment. An owner may instead choose a github.com blob URL pinned

to a full 40-character Git commit SHA. The canonical repository maintains one

automated validation receipt per marked submission and removes that receipt

when the source comment is deleted or edited to remove its marker. Treat the

receipt as a useful transport check, not p

… (nội dung đầy đủ có trong gói tải về)