How to use these prompts
Each prompt is written for a coding agent working inside your repository, such as Claude Code or Cursor. They work best when the agent already knows the Orwel rules, so do one of these first:
- Install the skill:
npx skills add hyperlabs-ai/hyper-skills/orwel - Or paste the CLAUDE.md analytics template into your project instructions
Run them in order the first time. After that, use the one you need. They are the measure step of the vibe coding loop, written so the agent gets it right on the first pass.
1. Install Orwel
Use it once, at the start, from the project root.
Install Orwel in this project. Detect the framework and package manager and install orwel@latest.
Read the key from a public env var with the right name for this framework
(NEXT_PUBLIC_ORWEL_KEY, PUBLIC_ORWEL_KEY or VITE_ORWEL_KEY). Put the development key in .env,
add an empty line to .env.example and make sure .env is in .gitignore. Never write the key in code.
Create one wrapper module that reads the var, warns and skips init if it is missing, and re-exports
orwel. Call orwel.init({ apiKey }) once, client side, when the app boots.
2. Propose the event catalog
Use it before instrumenting anything, so you review the plan instead of the diff.
Read the service layer, API routes and stores of this app (not the components) and propose an
Orwel event catalog of 10 to 30 codes, one per business action. Prefer Orwel catalog codes when
one fits (signup, login, onboarding_completed, project_created, invite_sent, purchase). Show a
table: code, tier (reach, activation, core loop, outcome, health), file and function where it
fires, track or conversion, properties, catalog or custom. Do not write code until I confirm.
3. Track the signup funnel
Use it to measure how many new accounts reach real progress.
Instrument the signup funnel with Orwel using catalog codes: signup when the account is created,
onboarding_completed when onboarding finishes, project_created when the first project is saved.
Fire each one right after the API call succeeds, from the service layer, once per action.
Call orwel.identify({ email, name }) right after signup succeeds. Import orwel only from the
wrapper module.
4. Track usage of one feature
Use it when you ship a feature and want to know whether people use it.
Track usage of the reports feature with Orwel. Fire report_exported after the export finishes
successfully, with the format as a property. If the feature has other actions that count as
usage, propose catalog codes for them. If a code is not in the Orwel catalog, list it so I can
register it in Features setup before you ship the code.
5. Record a lead from a form
Use it on every contact, demo, quote or newsletter form.
On submit of the contact form, after validation: call orwel.identify({ email, name, company })
and then await orwel.conversion('contact_form', { ...form data }) before redirecting or showing
the success message. Trim and lowercase the email. Guard against double submits with a loading
flag, wrap the Orwel calls in try/catch so they never block the submit, and do not use
orwel.form() on this form.
6. Identify users on login
Use it in apps with accounts, so visitors stop being anonymous.
Wherever a user signs in or a session is restored, call orwel.identify({ email, name }) with
whatever the auth user has, plus plan and company if available. Track login with the catalog
code after sign in succeeds. Do it in the auth service, not in components, and only once per
sign in.
7. Record a purchase with value
Use it on checkout or subscription success.
When a payment succeeds, await orwel.conversion('purchase', { email, amount, currency, plan,
order_id }). amount must be a number and currency an ISO code like USD. Fire it only after the
payment is confirmed, never optimistically, and only once per order.
8. Verify in Dev mode
Use it after any instrumentation change, before you deploy.
Run the app with the Orwel development key and debug: true. Trigger one of each: a page load,
a sign in with identify, every track code we added and one conversion with an email. Then tell
me exactly what to check in Orwel Dev mode: every request should be accepted, with no
event_not_found, invalid_field or conversion_no_email. List every file you changed and the code
each one fires.
9. Audit existing tracking
Use it on an app that already has tracking someone else wrote.
Find every Orwel call in this repo. Flag: track codes that may not be in the catalog, tracking
fired on clicks instead of after success, conversions that are not awaited or have no email,
orwel.form() on a form that also sends a conversion, imports that bypass the wrapper, and any
orwel_ key written in code. Propose a fix for each and wait for my confirmation.
10. Read usage through MCP before the next change
Use it once the Orwel MCP server is connected to your agent, before you plan the next feature.
Use the Orwel MCP tools to pull the last 14 days: lead analytics, conversions, and the issues
and signals Orwel detected (anomalies and funnel drops). Summarize what changed and what looks
broken. Then, with these numbers from the Features report: [paste adoption], propose the one
change most likely to move the main conversion, and keep its tracking correct.
The MCP server returns leads, visitors, conversions, campaigns and detected issues. Feature adoption and journey reports are in the dashboard, so paste them where the prompt says. Setup is in Claude Code analytics and Cursor analytics. This prompt is what closes the vibe coding feedback loop.
Adapting the prompts
- Swap the event codes for the actions your product has. Keep catalog codes when one fits.
- Keep the guardrails in every prompt: after success, once per action, await conversions, email included.
- If you configured journeys or features in the dashboard, the Implement tab gives you an agent prompt that lists every code and when to fire it. Use that instead of prompts 3 and 4.