Disciplinary & PIP Tracker

Disciplinary & PIP Tracker helps define a documented case timeline for performance issues. Its workflow opens a case, sets improvement goals and a review date, records the review and outcome, and ends with closure and appeal. It emphasizes dates and review points rather than storing opinions as the record.

The skill separates advice, review, conversion and build requests before producing artifacts. Advice receives a short recommendation and an offer of a relevant build. An explicit build request proceeds once essential missing facts are resolved. It asks one question at a time, reuses answers already supplied and stops when further answers would not change the deliverable. Unknown information remains unknown rather than receiving invented values.

Use it for a performance improvement plan, PIP tracker, disciplinary record or misconduct case log. It fits growth-stage businesses replacing informal memory or spreadsheets with an explicit case structure.

It produces empty templates and does not give legal advice. Employment law needs a qualified reviewer, and disciplinary cases require human review before action. The skill does not calculate payroll, tax, leave balances or KPIs. Automation, reminders and synchronization require an integration layer. Legal, tax and HR review is required before templates drive real decisions.

Inputs cover what happened, whether it is an isolated case or pattern, relevant policy, formal or informal stages, case ownership, involved people, written records and evidence location. The desired output can be a case record, plan or reporting. Fields identify the case, employee, department, manager and HR owner; link a performance review and issue; and record the issue summary, improvement goals, start, review and end dates, outcome, confidentiality, status and case ID. Case types cover misconduct, performance, attendance, policy breach and grievance. Confidentiality ranges from public to highly restricted, while statuses cover opening, investigation, hearings, decision, appeals and closure.

Requested artifacts can include CSV, SQL DDL, JSON Schema, Notion property mappings or an Excel workbook. The formats derive from one field list: CSV and JSON retain matching display names, while SQL uses normalized identifiers. Dates retain date types, money retains currency types and cross-table references retain relation types. Select options are a starting set that can be renamed to match the business.

One SQL example is:

CREATE INDEX idx_disciplinary_pip_tracker_status ON disciplinary_pip_tracker (status);

Templates are empty by default. Example rows are produced only on request and remain obviously synthetic. Sensitive identifiers should not be repeated unnecessarily during a requested review. Machine-readable data stays separate from explanatory prose and any material validation failures. Excel-compatible CSV uses UTF-8 with a byte order mark and accompanying guidance about number, date and currency columns. An XLSX workbook is a separate requested output rather than a renamed CSV.

The Notion output routes to notion-manual-import for CSV, property mappings, import steps and verification. Manual mappings require no connection. Requested live workspace changes require actual tool access, a verified target and authorization. Imported columns may initially be Text and need their mapped property types applied. Relation links resolve after both relevant databases are imported. A static mapping alone does not establish a completed workspace change.