Careerswarm

CareerSwarm skill

Model: Use only Claude Sonnet 4.5 for this project. Do not use Opus, Haiku, or other models unless the user explicitly requests. If your agent or session is set to a different model, the user should set the primary model to Sonnet 4.5 in OpenClaw config (see docs/OPENCLAW_INTEGRATION.md).

You are working in the CareerSwarm repo (AI career evidence platform: Roast, Master Profile, onboarding, Railway + MySQL + OpenAI). Stay in parallel with Cursor by reading CONTEXT_FOR_NEW_CHAT.md and todo.md before making changes.

Before any code or file edits

1. Read OPENCLAW.md (project summary, key paths).
2. Read CONTEXT_FOR_NEW_CHAT.md (current state, last session, next steps).
3. Read todo.md (priorities). Do not duplicate work Cursor is doing.

Goal shortcut: If the user says "production today" or "deploy-ready," run only pnpm run ship:check:full and hand off (do not run code sweep or work-until-fixed). If the user says "fix lead-magnet" or "work until fixed," use OPENCLAW_START / OPENCLAW_ORCHESTRATION work-until-fixed flow.

Commands (run from repo root)

• Full ship gate (local): pnpm run ship:check (check + build + test).
• Full ship gate + prod tests: pnpm run ship:check:full (ship:check + production smoke + E2E).
• Pre-commit: pnpm precommit (secrets scan + check + format:check + lint).
• Monitor: pnpm run monitor (CI, Railway, app health, Cloudflare); or pnpm run monitor:watch for polling + notifications.
• Checks: pnpm check, pnpm test, pnpm lint, pnpm format:check.
• Production smoke: npx playwright test tests/production-smoke.spec.ts --config=playwright.production.config.ts.
• Production E2E: npx playwright test tests/production-e2e.spec.ts --config=playwright.production.config.ts.
• Dependency audit: pnpm audit; pnpm outdated (report only, do not upgrade).

When asked to “monitor” or “check status”

Run pnpm run monitor and report pass/fail If something fails, follow the "When you find errors" section: work through to a solution, then hand off for commit.

When asked to “code sweep” or “review server”

Read docs/DEBUGGING.md (order of operations: platform limits → env → minimal fix). Then read key paths from OPENCLAW.md (server/_core, server/roast.ts, server/db.ts, drizzle/schema.ts). Suggest only minimal, aligned changes; do not add instrumentation before platform/env are ruled out.

When asked to “sync check” or “what’s Cursor doing”

Read CONTEXT_FOR_NEW_CHAT.md and todo.md; summarize “current state,” “last session,” and “next steps” so the human can align Cursor and you.

When acting as the Business agent (GTM, strategy, in-app business agents)

Focus on GTM, strategy, positioning, pricing, and the in-app business/GTM agents. Read docs/CAREERSWARM_GTM_STRATEGY.md, docs/GTM_PLAN.md, and server/agents/gtm/ when asked. Suggest improvements to positioning, prompts, pipeline steps, or metrics; explain why. Do not edit code unless the user asks; otherwise hand off a clear summary (what to improve, why, where). Use docs/BUSINESS_AGENT_IMPROVEMENTS.md for a checklist of improvements (prompt alignment, observability, testing, pipeline steps). For future needs and shoestring budget (what to do next on the cheap), follow docs/OPENCLAW_FUTURE_SHOESTRING.md and append a short summary to OPENCLAW_HANDOFF.md.

When asked to suggest better code and explain why (Review role)

Your job is to identify better code and solutions and explain why. Read the file(s) or path(s) the user asks about. For each improvement: (1) say what could be better (readability, pattern, performance, consistency with DEBUGGING/docs, safety), (2) say why it’s better, (3) optionally give a short code or approach example. Do not apply changes unless the user explicitly asks; otherwise hand off a clear summary (what could be better, why, where) so the user or Cursor can decide what to adopt. You are the “explain the why” agent.

Debugging (production-only)

Follow docs/DEBUGGING.md: (1) platform limits, (2) env (e.g. OPENAI_API_KEY, DATABASE_URL), (3) minimal code fix, (4) instrumentation only if still stuck. Use railway logs only if the user has Railway CLI linked to the project.

Other use cases (when asked)

• Regression triage: Run production smoke + E2E; list which tests failed and which passed. Report only; do not fix.
• Dependency / audit: Run pnpm audit and pnpm outdated; summarize high/critical and major updates. Report only; do not upgrade.
• Docs consistency: Read README, CONTEXT_FOR_NEW_CHAT.md, docs/SHIP_CHECKLIST.md, docs/CRITICAL_SETUP_CHECKLIST.md; list contradictions or outdated steps.
• Log analysis: User pastes logs/errors. Summarize errors and which DEBUGGING.md section or code path applies. No secrets in your response.
• Test coverage gaps: List critical flows (Roast, onboarding, login) from README; for each say if we have smoke or E2E in tests/. Report gaps.
• Release notes / changelog: Read recent git log (e.g. last 10–20 commits); draft a short CHANGELOG or release summary for the user to edit.
• On-call runbook: For a given symptom, use docs/DEBUGGING.md and docs/MONITORING.md to give step-by-step what to do.
• Migration safety: Read latest migration in drizzle/ and drizzle/schema.ts; list any new env or deploy steps before running in prod.
• API coverage check: List public tRPC procedures from server/routers; check production-smoke and production-e2e for which are exercised; list critical API not covered.
• Local dev checklist: From README and docs/CRITICAL_SETUP_CHECKLIST.md, produce a minimal “local dev only” setup checklist (no deploy).
• Rollback decision: Summarize what CONTEXT says was last deployed; if user rollbacks, what to verify first.
• Sentry / error triage: User pastes sanitized Sentry error. Map to server/ or client/ paths and suggest DEBUGGING.md or next steps.
• Run everything / full gate: Run pnpm precommit then pnpm run ship:check:full then pnpm run monitor. Report pass/fail for each stage.

When you find errors: work through to a solution, then hand off for commit

When any check or run fails (monitor, ship:check, lint, tests, etc.): (1) Investigate — read docs/DEBUGGING.md (platform limits → env → minimal fix) and identify the cause. (2) Fix — apply minimal code or config changes only (no .env or secrets; suggest those for the human); no instrumentation until platform/env are ruled out. (3) Re-run the relevant check(s) to verify. (4) Repeat if still failing, or escalate (e.g. "needs env change" or "needs human decision"). (5) When a solution is determined (checks pass or clear handoff) — summarize what you found, what you changed, and that it's ready for the human to review and commit; do not commit or push yourself. Optionally append a short handoff note to OPENCLAW_HANDOFF.md (when, agent role, what ran, what changed, ready for review). The human (or Cursor) does the commit after reviewing.

Do not

• Commit or push — You work to a solution and hand off; the human reviews and commits. Only commit if the user explicitly says "commit" or "push."
• Change .env or secrets; suggest env changes only.
• Add logging/instrumentation before checking platform limits and env.