Build with an agent
Install version-matched Cavuno SDK skills and give a coding agent a verifiable setup workflow.
A
JInstall the SDK’s own skill corpus so a coding agent reads instructions that match the package version in your project. The skills cover the client, jobs, authentication, sessions, errors, feature gates, SEO, and runtime verification.
The agent still edits your application. The setup command only copies documentation—it does not generate routes, create environment files, or deploy anything.
Prerequisites
- Node.js 20 or later.
- An existing project with a
package.json. - A coding agent that supports Agent Skills, such as Codex, Claude Code, or Cursor.
- Your
pk_…publishable key from Settings → Developer → SDK in the Cavuno dashboard. The SDK uses Cavuno’s production API automatically. - A clean understanding of which existing project conventions the agent must preserve.
1. Install the package
Run this from the directory containing your application’s package.json:
npm install @cavuno/board
2. Copy the matching skills
1npx @cavuno/board setup
The command copies the core cavuno-board-* skills to the project’s supported agent directories, including .claude/skills, .cursor/skills, and .agents/skills. If none exists, it creates .claude/skills.
For a project with @tanstack/react-start in its dependencies, setup also copies the TanStack Start flavor. Other frameworks receive the framework-agnostic core skills.
The output names the detected framework, destination directories, and every copied skill. It ends with the required board configuration:
1PUBLIC_CAVUNO_BOARD=pk_...
Ask the agent to adapt the board variable to the framework’s public-environment convention—for example, NEXT_PUBLIC_… in Next.js or VITE_… in a client-side application. Only set baseUrl when Cavuno gives you a non-production origin for development or staging.
3. Give the agent a bounded prompt
Use a prompt that includes the outcome and the required checks:
123456Set up my Cavuno board using the installed cavuno-board-setup skill.First inspect this project’s framework, routes, environment conventions,and test commands. Create one shared client, render the board context andthe first jobs page, handle not-found API errors, and run the project’stypecheck plus the Cavuno smoke checks. Do not add authentication yet.Show me the proposed files before editing them.
Give the agent the real environment values through your normal secret or environment workflow—not in the prompt transcript if that transcript is shared. The publishable key is public-safe, but keeping configuration in one standard place prevents accidental substitution with a bearer token later.
4. Review the proposed boundary
Before approving edits, confirm that the proposal:
- Creates one client from environment values instead of hard-coding a board slug.
- Uses the
pk_…key asboard. - Fetches public data without inventing an authentication requirement.
- Keeps any future user session out of a shared server client.
- Preserves the canonical job-detail route
/companies/:companySlug/jobs/:jobSlug. - Gates optional routes using
board.context().features.
If the agent proposes an SDK method that is not in the installed skills or the SDK reference, stop and verify it against the installed package before continuing.
5. Verify the implementation
Run the project’s normal typecheck and tests, then run the SDK doctor:
1npx @cavuno/board doctor --frontend http://localhost:3000
Replace the URL with the running frontend origin. Run the command from a shell where PUBLIC_CAVUNO_BOARD is exported—the CLI does not load a framework’s environment file for you. Set PUBLIC_CAVUNO_API_URL only for a Cavuno-supplied non-production override. Doctor prints each check as pass, fail, or skip. A skipped check is explicitly not verified; read the summary rather than treating exit code 0 as proof that every tier ran.
At minimum, open the built page and confirm that its board name matches Cavuno and its jobs come from the expected board. An invalid job slug should enter the application’s not-found path.
Keep the skills current
The copied files are a versioned artifact. After upgrading @cavuno/board, rerun:
1npx @cavuno/board setup
Commit the copied skills if contributors and CI agents should all use the same corpus. Do not hand-edit the copied Cavuno skills; a later setup run intentionally replaces them.
Next, read How headless Cavuno works to understand which responsibilities belong to Cavuno, the SDK, and your frontend.