Alumni & Re-hire Tracker

Alumni and Rehire Tracker helps define the smallest useful register for former employees. Its recommended workflow records a departure, keeps relevant details, and considers rehire when a role opens. The register should have a reason to be revisited; tie review to vacancies rather than maintaining a standing newsletter.

The default response is a short recommendation. A request to set up, build, or create asks for artifacts; an advice question receives advice, and a review request receives a check of the supplied process. A process already kept in a spreadsheet or inbox can be captured before proposing its replacement. The skill asks only for missing information that could change the output, one question at a time, and keeps unknown answers unknown.

Its intake covers how many people have left and when, former roles and useful skills, reasons to consider rehiring, warm contacts, contact consent, check-in practices, the current record, and whether an alumni register, rehire view, or both are needed. Confirmed facts stay separate from unanswered questions.

Use it for an alumni tracker, rehire tracker, former-employee register, or past-employee list. It fits the Exit layer at Scale stage. A representative request is:

Four good people left last year and we only noticed when a role came up.

The skill does not calculate payroll, tax, leave balances, or KPIs. It does not contact anyone, verify consent, or make hiring decisions. Legal, tax, and HR review remains necessary before the design informs real decisions. Privacy or disciplinary cases need qualified human review.

The shared field list has twelve fields: Alumni Name, Former Department, Former Job Title, Last Working Day, Rehire Eligible, Personal Email, LinkedIn, Current Company, Last Contact, Re-engage Date, Notes, and Alumni ID. Dates remain dates, eligibility is boolean, contact email and LinkedIn retain their email and URL types, and notes are long text. There are no select fields or link fields in this module.

On request, it derives CSV, SQL DDL, JSON Schema, or a Notion property mapping from that list. Display names remain consistent across CSV and JSON; normalized SQL names are documented. Imported identifiers are preserved as text in Notion rather than replaced by a new identifier. CSV needs date formatting after import and uses UTF-8 with a byte order mark for Excel compatibility. An actual Excel workbook is produced only when requested.

Templates stay empty. Example rows require an explicit request and must be clearly synthetic. Sensitive information supplied for a review should not be repeated unnecessarily or inserted into generated templates.

Requested Notion output is routed to notion-manual-import for the CSV, property mapping, import steps, and verification checklist. Manual output needs no connection. A live workspace write requires verified tool access, an identified target, and authorization; a static mapping is not a completed workspace change. The module provides no automation, reminders, or synchronization.