Kelly Instructor Sourcing

Kelly Instructor Sourcing

Turn a rough "who are we looking for" hypothesis into a scored, triaged pool of 講師/instructor candidates: capture the search criteria and a three-axis scoring rubric, score each candidate a human found on a recruiting-style platform, and record the connection state as it happens in the real world. Everything in v1 is sandbox-only — see Product Boundary.

Subcommands

Run setup, then criteria, then review the first time. Afterwards, review repeats as new candidates surface. There is no send subcommand: first-stage scope is 获取信息 → 建立连接 → 录入数据 only, and the actual WeChat exchange happens manually outside this app — review records that it happened, it never performs it.

Dependencies

Before changing the app:

1. Read $kelly-app-skill-creator for product behavior, responsive UI, and the canonical content/kelly-instructor-sourcing-app/ artifact.
2. Read $busabase for target Space, ChangeRequests, review, merge, and Vault behavior.
3. Read $busabase-app-creator for runtime, SDK, security, validation, and AirApp deployment.
4. Read references/instructor-sourcing-schema.md before changing fields, statuses, or the scoring rubric shape.

If a dependency is unavailable, finish deterministic local artifact work but stop before its Busabase or AirApp operation and name the missing dependency. Never introduce a second backend.

Product Boundary

• Sandbox only, deterministic data only. ?demo=1 seeds a fixed set of fictional candidates and a fixed criteria record. No live scraping, no real candidate data, and no real platform or messaging credential exists anywhere in this skill.
• Never connects to a real sourcing-platform account. This skill does not authenticate against, browse, or automate any recruiting-style platform. That integration is explicitly out of scope until its automation boundaries, account-safety limits, and personal-data handling rules have been researched and confirmed — none of which has happened yet.
• Never sends a message and never automates a WeChat add. Guiding a candidate to WeChat and adding them is entirely human-performed outside this app. The app's only job once a human tells it that happened is to record the date on that candidate's own row.
• Scope is 获取信息 → 建立连接 → 录入数据 only. Post-cooperation scoring, meeting booking, and call/session recording or archiving are out of scope for v1 and must not be implied by any screen or copy.
• Score what a human already assessed. The three-axis rubric (endorsement, expertise, teaching-service) exists so a human's judgment is captured consistently, not so the app infers a score on its own.
• Every candidate carries its scoring evidence. match-notes is human-editable free text explaining the scores; do not auto-generate scoring text that was not reviewed by a person.

Product Overlay

• Research — candidate discovery. v1 is manually or demo-seeded only; there is no live scraping. This represents 获取信息.
• Plan — score each candidate 0-100 on three rubrics (endorsement, expertise, teaching-service), derive an overall score, and hold a screening attention queue of candidates still needing a decision.
• Action — a human marks a screened candidate qualified or not-qualified; later, once a real-world WeChat add has actually happened outside the app, the human records it and the candidate moves to connected. Writing that record into Busabase is 录入数据 — there is no separate send step.
• Retrospective — out of scope for v1. No post-cooperation scoring, meeting outcomes, or call archiving.

/kelly-instructor-sourcing setup

Confirm the Space first. Setup is idempotent and resolves resources from the declared Folder; nobody copies Node IDs into config. Re-read after every ChangeRequest and report a pending CR rather than claiming the workspace exists. In demo mode (?demo=1) no Busabase connection happens at all.

/kelly-instructor-sourcing criteria

Capture or update, in the kelly-instructor-sourcing-criteria record:

• the search-keyword and experience/activity filter hypotheses;
• plain-language "what good looks like" text for each of the three rubric axes (endorsement, expertise, teaching-service);
• the overall qualify-threshold a candidate's score must clear to be marked qualified by a human.

Put uncertainty into the rubric text; never present a filter hypothesis as a confirmed platform capability.

/kelly-instructor-sourcing review

For every candidate record in kelly-instructor-sourcing-candidates:

• name, public platform headline, and which search context surfaced them;
• a 0-100 score per rubric axis, with match-notes explaining the evidence;
• the derived overall score;
• current status.

A human marks qualified or not-qualified once all three axis scores are recorded. Once a human has actually added the candidate on WeChat outside this app, review records wechat-added-at and then connected with logged-at. Never skip straight to connected without a recorded wechat-added-at — that field is the evidence the real-world step happened.

Busabase Resources

See references/instructor-sourcing-schema.md for exact field slugs and status transitions.

Screens

• #/criteria — search-criteria hypothesis and the three rubric axes, editable.
• #/all — every candidate, list/detail, sorted so screening candidates needing a decision surface first.
• #/qualified — candidates a human has marked qualified, whether or not a WeChat add has been recorded yet.
• #/connected — candidates with a recorded real-world WeChat add.
• #/settings/<tab> — commands, guide, resources, and connection.

Stop Conditions

Stop rather than guess when the search criteria or rubric text is missing; a candidate lacks a required field or an axis score before a qualify/reject decision; a candidate is marked connected without a recorded wechat-added-at; the target Space is ambiguous; or a required dependency is unavailable. Never attempt a real connection to a sourcing platform or a messaging channel from this skill — that boundary is unresearched and out of scope for v1.

App Contract

• Keep the canonical Hono project in <skill-root>/content/kelly-instructor-sourcing-app/; use the same source locally and in AirApp.
• Store criteria and candidates only in Busabase through busabase-sdk.
• Demo data (?demo=1) is explicit, deterministic, non-persistent, and cannot write anywhere — mutations only touch an in-memory array.
• There is no send/execution path in v1 at all: no outbound message, no platform automation, and no messaging credential anywhere in this skill.
• Keep the desktop sidebar/list/detail shell, true mobile list/detail flow, hash routes, and responsive Help & Settings from the creator contract.