Greenhouse

Build a local-only applicant tracker for a solo or two-person hiring pipeline. No cloud, no accounts, no telemetry.

Stack, non-negotiable:
- Next.js 15, App Router, TypeScript, Tailwind.
- SQLite via better-sqlite3, single file at ./data/ats.db. Schema in migrations run at boot.
- Resume/attachment files stored on local disk under ./data/files, referenced by path in the DB.
- No auth. This runs on localhost for one person.

Data model:
- roles: title, team, status (open/closed), created_at, notes markdown.
- candidates: name, email, phone, source (referral/inbound/outbound/agency), role_id, stage, created_at, archived_at nullable.
- stages are per-role and ordered: default Applied, Screen, Interview, Onsite, Offer, Hired, Rejected.
- notes: candidate_id, body markdown, created_at.
- scorecards: candidate_id, interview_name, per-attribute rating 1-4, overall recommendation (strong no/no/yes/strong yes), free text, created_at.
- attachments: candidate_id, filename, path, uploaded_at.
- events: append-only log of every stage change and field edit with timestamp. Never delete rows here.

UI:
- /roles list, /roles/[id] shows a Kanban board of that role's stages with drag and drop between columns.
- /candidates/[id] is the main screen: header with name, role, stage, source; tabs for Notes, Scorecards, Attachments, History (from events).
- Global search across candidate name, email, and note bodies. Use SQLite FTS5.
- Quick add: paste a name and email, pick a role, done in one modal.
- A per-role funnel count strip: how many in each stage, and median days in stage.

Also include:
- Structured interview kits: per-role, define a named interview with 3-6 attributes to rate. Scorecards are created from a kit so ratings stay comparable.
- CSV export of all candidates and scorecards, and a JSON dump of the whole DB.
- A retention helper: a page listing candidates archived more than N days ago with a one-click purge that deletes their files and PII but keeps an anonymized events row. Default N in .env.

Explicitly out of scope, do not build or stub:
- Email sending, calendar scheduling, job board posting, a public careers page, multi-user permissions, any OAuth.

Deliver a README with setup, `npm run dev`, and a seed script that creates two roles and eight fake candidates. Secrets and config in .env.example.

# AGENTS.md — Build guide for Greenhouse

## Project scope
A local applicant tracker: add roles, drag candidates through stages, attach resumes and notes, and fill structured scorecards, all in one SQLite file.

Catalogue verdict: no. An agent can absolutely build you a candidate tracker: stages, notes, a Kanban board, a scorecard form. That is maybe five percent of what Greenhouse is being paid for. The rest is job board syndication, a hosted careers page that survives traffic, interview scheduling against a dozen calendars, structured interview kits, permissioned access for hiring managers who are not you, audit trails, EEOC and OFCCP reporting, GDPR retention and deletion workflows, and a very long tail of HRIS and background check integrations. Hiring is also one of the most litigated processes in a company, which means the boring parts (who saw what, when, and what got deleted) are the product. Solo or two-person hiring is genuinely fine on a DIY tracker; anything with a legal surface is not.
Use the implementation prompt below to define the deliverable. Complete each phase's acceptance checks before extending the scope.

## Working agreement
- Inspect the repository and its existing instructions before choosing paths, dependencies or commands. Keep one coherent stack and explain changes to the proposed architecture.
- Plan a vertical slice that accepts a real input and produces the useful output described below. Persist only the state the prompt calls for; respect memory-only and upstream-managed workflows. Use fixtures only when they are clearly labelled.
- After scaffolding, document the actual install, development, check and build commands in README and keep them synchronized with the package or project manifest. Do not report commands as successful unless they ran.
- Work in small steps. At handoff, list implemented flows, checks actually performed, remaining blockers, and any credentials or provider setup the owner must supply.
- Do not publish, spend money, contact customers, delete source data or run irreversible migrations without the project owner's authorization.

## Prerequisites
- Node 20+ and a place to run it (localhost is fine)
- Somewhere to put resume files (local disk)
- Your own inbox for actually talking to candidates

## Stack and architecture
- SQLite via better-sqlite3, single file at ./data/ats.db. Schema in migrations run at boot.
- Data model:.
- Interface for this applicant tracking / recruiting workflow: a focused applicant tracking / recruiting input, review, and export interface.

## Security and data integrity
- Email sending, calendar scheduling, job board posting, a public careers page, multi-user permissions, any OAuth.
- Validate imported records and file paths; keep user data within the storage location named in the prompt.
- State the practical limit: Job board syndication and a hosted careers page candidates can find.

## Agent implementation rules
- Project rule, data: Data model:.
- Project rule, behavior: roles: title, team, status (open/closed), created_at, notes markdown.
- Project rule, recovery: Email sending, calendar scheduling, job board posting, a public careers page, multi-user permissions, any OAuth.

## Optional agent skills and references
No installable skill is listed for this guide; use the project rules and the stack documentation.

Read the linked SKILL.md and its dependencies before adding a skill. Select only the skills matching this project's runtime and task; their documentation does not supply API access, credentials or approval to perform external actions. Pin the reviewed revision where the tool supports it. Follow the chosen agent's documented project-level installation mechanism.

## Distribution ideas
These are optional planning notes. Obtain the owner's approval before publishing or contacting anyone.
- Demonstrate this applicant tracking / recruiting operation with sample or user-owned data: roles: title, team, status (open/closed), created_at, notes markdown.
- Show a concrete result or export: CSV export of all candidates and scorecards, and a JSON dump of the whole DB.
- State the practical limit: Job board syndication and a hosted careers page candidates can find.

## Engineering roadmap
1. Phase 1, architecture and data: SQLite via better-sqlite3, single file at ./data/ats.db. Schema in migrations run at boot. Data model:.
2. Phase 2, implement: roles: title, team, status (open/closed), created_at, notes markdown.
3. Phase 3, implement: candidates: name, email, phone, source (referral/inbound/outbound/agency), role_id, stage, created_at, archived_at nullable.
4. Phase 4, review and output: stages are per-role and ordered: default Applied, Screen, Interview, Onsite, Offer, Hired, Rejected. CSV export of all candidates and scorecards, and a JSON dump of the whole DB.
5. Phase 5, recovery and acceptance: Email sending, calendar scheduling, job board posting, a public careers page, multi-user permissions, any OAuth. Verify this invariant with a saved fixture: A rejected or withdrawn request cannot change the approved balance; a policy edit must not rewrite past decisions. State the practical limit: Job board syndication and a hosted careers page candidates can find.

## Paid-product capabilities outside this build
- Job board syndication and a hosted careers page candidates can find
- Interview scheduling that reads real interviewer calendars
- Multi-user permissions, so hiring managers can review without seeing everything
- Compliance scaffolding: EEOC/OFCCP reporting, consent capture, GDPR retention and deletion, audit logs
- Integrations with HRIS, background checks, assessments, and every recruiter tool your team already uses

## Implementation prompt
Build a local-only applicant tracker for a solo or two-person hiring pipeline. No cloud, no accounts, no telemetry.

Stack, non-negotiable:
- Next.js 15, App Router, TypeScript, Tailwind.
- SQLite via better-sqlite3, single file at ./data/ats.db. Schema in migrations run at boot.
- Resume/attachment files stored on local disk under ./data/files, referenced by path in the DB.
- No auth. This runs on localhost for one person.

Data model:
- roles: title, team, status (open/closed), created_at, notes markdown.
- candidates: name, email, phone, source (referral/inbound/outbound/agency), role_id, stage, created_at, archived_at nullable.
- stages are per-role and ordered: default Applied, Screen, Interview, Onsite, Offer, Hired, Rejected.
- notes: candidate_id, body markdown, created_at.
- scorecards: candidate_id, interview_name, per-attribute rating 1-4, overall recommendation (strong no/no/yes/strong yes), free text, created_at.
- attachments: candidate_id, filename, path, uploaded_at.
- events: append-only log of every stage change and field edit with timestamp. Never delete rows here.

UI:
- /roles list, /roles/[id] shows a Kanban board of that role's stages with drag and drop between columns.
- /candidates/[id] is the main screen: header with name, role, stage, source; tabs for Notes, Scorecards, Attachments, History (from events).
- Global search across candidate name, email, and note bodies. Use SQLite FTS5.
- Quick add: paste a name and email, pick a role, done in one modal.
- A per-role funnel count strip: how many in each stage, and median days in stage.

Also include:
- Structured interview kits: per-role, define a named interview with 3-6 attributes to rate. Scorecards are created from a kit so ratings stay comparable.
- CSV export of all candidates and scorecards, and a JSON dump of the whole DB.
- A retention helper: a page listing candidates archived more than N days ago with a one-click purge that deletes their files and PII but keeps an anonymized events row. Default N in .env.

Explicitly out of scope, do not build or stub:
- Email sending, calendar scheduling, job board posting, a public careers page, multi-user permissions, any OAuth.

Deliver a README with setup, `npm run dev`, and a seed script that creates two roles and eight fake candidates. Secrets and config in .env.example.


## Completion evidence
Demonstrate the prompt's acceptance scenarios against the scoped workflow. Include setup from a clean checkout and failure recovery. Check persistence across restart and export/restore only for the state the prompt says to store; for memory-only tools, confirm that temporary content is discarded as specified. Record actual results and remaining limitations. A detailed plan alone does not establish a working replacement.