Contributors

This page is for engineers and agents working inside the Veref monorepo.

Where to start

1. Read Product, Product Concepts, and User Flows.
2. Read Architecture, Runtime Surfaces, and Package Boundaries.
3. Run the setup in Local Development.
4. Use Troubleshooting when onboarding friction appears.

Working model

The repo assumes a split between:

• runtime skills in skills/
• developer and monorepo skills in .agents/skills
• agent memory in .agents/memory

Local agent runtimes expect these linked paths:

• .claude/skills -> .agents/skills
• .claude/memory -> .agents/memory
• .codex/skills -> .agents/skills
• .codex/memory -> .agents/memory

Use ./skills.sh install to create or repair those links and ./skills.sh status to verify them.

What contributors should treat as source of truth

• package.json for workspace commands
• turbo.json for task orchestration
• .env.example for required environment keys
• .shipcode/setup.json for setup and verification expectations
• README.md for the top-level product and repo summary
• shipped apps/* and packages/* source for current behavior

Current repo expectations

• keep docs aligned to shipped code, not aspirational features
• keep recruiter control central to product explanations
• treat candidate and referee flows as public-flow paths, not internal desk UX
• respect package and surface boundaries instead of collapsing everything into one layer

Surface owners in practice

• use apps/* for runtime-specific pages, routing, and entrypoints
• use packages/* for shared contracts, workflow logic, integrations, persistence, UI, and desktop bridge code
• keep contributor guidance in apps/docs

Verification contract

The repo-level verify commands are:

bun run typecheck
bun run test
bun run build

Before broad verification, the setup contract expects:

bun install --frozen-lockfile

Contributor docs to keep nearby

• Local Development
• Deployment & Operations
• Troubleshooting
• Documentation Boundaries