Xiaohongshu lead screening and follow-up

Turn scattered Xiaohongshu posts into local records where every judgement traces back to evidence from the original post, survive across days, and never duplicate when you search again. Not affiliated with Xiaohongshu; it only reads, organises and records locally.

What it does

• Read or import: platform search results, post bodies and comments, and lead lists you already have all land in one record set. Importing an older list keeps its past conclusions as historical evidence awaiting review instead of treating them as current customers.
• Deduplicate: the same note does not get inserted twice, a search card never overwrites details already read, and re-running the same keywords adds nothing new.
• Keep evidence: post bodies and comments are stored as evidence with stable IDs. A judgement must cite those IDs, and citing evidence that belongs to another lead is rejected outright.
• Judge and screen: tell buyer requests from freelancer advertisements, then screen by budget, willingness to accept AI and date range into match, pending or excluded with reason codes. Unknown budgets or acceptance stay pending instead of counting as a match.
• Track stages: contacted, requirements reviewed, accepted, delivered and closed. Skipping a stage is rejected and repeating the current one is idempotent.
• Export: CSV or JSON, without ever overwriting an existing file.

Where the data comes from

Search coverage is not guaranteed: a normal run can still be partial and carries an explicit "coverage unknown" warning. Partial is not complete, and results arrive together with the warnings.

Life of a lead

1. After reading or importing, it appears in the pending list with its post link and evidence.
2. Read the evidence, then judge: conclusion, reason, demand type (buyer or seller), AI acceptance and budget.
3. Screening returns match, pending or excluded with the reason.
4. Record facts that already happened as stages such as contacted or requirements reviewed.
5. Export CSV or JSON when you need to hand it over.

When a post is updated, earlier judgements are marked stale and screening stops relying on them.

What the output looks like

"key","title","url","published_at","observed_at","stage","decision","review_stale","reason","ai_acceptance","budget","currency"
"xiaohongshu:synthetic-edit-001","Example: short video editing request","https://www.xiaohongshu.com/explore/synthetic-edit-001","2026-10-01T00:00:00Z","2026-10-01T10:00:00Z","discovered","priority","false","Synthetic example text asks for editing, accepts AI and states an 800 CNY budget.","accepted","800","CNY"
"xiaohongshu:synthetic-edit-002","Example: editing project, budget unstated","https://www.xiaohongshu.com/explore/synthetic-edit-002","","2026-10-01T10:00:00Z","discovered","unreviewed","false","","unknown","",""

The rows above are real output from the repository's example data. Each row falls back to the evidence it cites rather than leaving a bare conclusion.

Boundaries

• Sends no direct messages, publishes nothing, never accepts work on your behalf and schedules no jobs.
• Does not replace a browser or a login session: you handle sign-in and captchas yourself, and verification is never bypassed.
• No OCR and no LLM: text inside screenshots has to be recognised by the host and imported as evidence.
• Stores normalised fields only: no cookies, access tokens or signed links from raw responses.

Data and privacy

Records live in the operating system's user data directory by default, never inside the skill folder or a shared package. You can point it at your own database file, one per account or workspace. Post bodies, authors and comments may still contain personal information and remain your local data; review them against your own use case before exporting. Examples, tests and release packages contain no real accounts, leads or operational data.

MIT License. For fuller contracts and boundaries see the repository's CLI reference, data model and provider integration.