kelly-instructor-sourcing
Run a Busabase-backed sandbox desk for scoring and triaging course-instructor ("讲师") candidates found on a recruiting-style platform. Use whenever the user invokes $kelly-instructor-sourcing or /kelly
Files44
View on GitHubSKILL.mdskills/kelly-instructor-sourcing/SKILL.md
GitHubKelly 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
| Invocation | What to do |
|---|---|
/kelly-instructor-sourcing setup |
Create or adopt the Busabase Folder and two Bases, then verify them. |
/kelly-instructor-sourcing criteria |
Capture or edit the search-criteria hypothesis and the three-axis scoring rubric. |
/kelly-instructor-sourcing review |
Enter or update candidate leads, score them against the rubric, and move them through the queue. |
/kelly-instructor-sourcing |
Open the desk and report the current bounded next step. |
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:
- Read
$kelly-app-skill-creatorfor product behavior, responsive UI, and the canonicalcontent/kelly-instructor-sourcing-app/artifact. - Read
$busabasefor target Space, ChangeRequests, review, merge, and Vault behavior. - Read
$busabase-app-creatorfor runtime, SDK, security, validation, and AirApp deployment. - Read
references/instructor-sourcing-schema.mdbefore 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=1seeds 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-notesis 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
screeningattention queue of candidates still needing a decision. - Action — a human marks a screened candidate
qualifiedornot-qualified; later, once a real-world WeChat add has actually happened outside the app, the human records it and the candidate moves toconnected. 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-thresholda candidate's score must clear to be markedqualifiedby 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-notesexplaining 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
| Resource | Purpose |
|---|---|
kelly-instructor-sourcing-criteria |
One search-criteria hypothesis and the three-axis scoring rubric text, plus the qualify threshold. |
kelly-instructor-sourcing-candidates |
One row per candidate with headline, search context, per-axis and overall scores, notes, status, and connection timestamps. |
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 soscreeningcandidates needing a decision surface first.#/qualified— candidates a human has markedqualified, 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.