Skip to main content
Ona works best when you treat it like a teammate with explicit context and a clear definition of “done.” This page gives end-to-end recipes for common tasks. If you are new to Ona, read Best practices first, then come back here for concrete recipes.

​
How to read these recipes

Each recipe includes:
  • When to use it: what task this solves.
  • Steps: with example prompts.
  • Context notes: what Ona sees automatically vs what you should provide.
  • Verification: how to check the output.

​
Explore a codebase

Use this when you are onboarding, inheriting a service, or trying to understand a request flow. Steps:
  1. Open a new environment for the repository.
  2. Prompt Ona with the area you want to understand:
Explain how the authentication flow works in this codebase.

Include:
- A summary of each module's responsibilities
- What data is validated and where
- One or two gotchas to watch for when changing this
  1. Follow up with specific questions:
Summarize the request flow as a numbered list of steps. List the files involved.
Context notes:
  • Ona reads your AGENTS.md and codebase automatically.
  • For large monorepos, point Ona at the relevant directory: “Focus on the backend/auth/ directory.”
Verification:
  • Ask Ona to produce a checklist or diagram you can validate against the code.

​
Fix a bug

Use this when you have a failing behavior you can reproduce. Steps:
  1. Give Ona a reproduction recipe and the files you suspect:
Bug: Clicking "Save" on the settings screen shows "Saved" but doesn't persist.

Repro:
1. Start the app: npm run dev
2. Go to /settings
3. Toggle "Enable alerts"
4. Click Save
5. Refresh: the toggle resets

Constraints:
- Do not change the API shape.
- Keep the fix minimal and add a regression test.

Start by reproducing the bug, then propose a patch and run checks.
Context notes:
  • You provide: repro steps and constraints. These matter more than a high-level description.
  • Ona provides: command output, discovered call sites, and any stack traces it triggers.
Verification:
  • Ask Ona to re-run the repro steps after the fix:
After the fix, run lint + the smallest relevant test suite. Report the commands and results.

​
Write tests

Use this when you want to add test coverage for existing code. Steps:
  1. Point Ona at the function or module:
Add a test for the invert_list function in src/transform.ts.
Cover the happy path plus edge cases.
Follow conventions used in other tests in this directory.
Context notes:
  • Ona reads existing test files to match conventions (test framework, assertion style, file naming).
  • For table-driven tests, mention the pattern: “Use the same table-driven pattern as the other tests in this package.”
Verification:
  • Ask Ona to run the tests and report results:
Run the test suite for this package and report pass/fail.

​
Prototype from a screenshot

Use this when you have a design mock or UI reference and want a working prototype. Steps:
  1. Attach the image by dropping it into the prompt box or pasting from clipboard.
  2. Provide constraints and structure:
Create a new dashboard page based on this image.

Constraints:
- Use React, Vite, and Tailwind. Write in TypeScript.
- Match spacing, typography, and layout as closely as possible.

Deliverables:
- A new route/page that renders the UI
- Any small components needed
- Instructions to run it locally
Context notes:
  • The image provides visual requirements, but you still need to specify implementation constraints (framework, routing, component style).
  • For non-obvious behavior, describe it in text: hover states, validation rules, keyboard interactions.
Verification:
  • Ask Ona to start a preview server:
Start a preview server and give me the URL to view the prototype.

​
Raise a pull request

Use this when you are done with changes and want to open a PR following your team’s conventions. Steps:
  1. Encode your PR process in a /create-pr skill (see Skills). Or use a prompt directly:
Raise a draft PR for a branch starting with my initials.
Get my initials from the configured git username.
Check for manual file changes before creating the PR description.
Make sure you capture all changes in this environment.

Follow this template:

## Description
<!-- Describe your changes in detail -->

## Related Issue(s)
<!-- List the issue(s) this PR solves -->
Fixes <issue>

## How to test
<!-- Provide steps to test this PR -->
Context notes:
  • Ona reads your git config for username and branch naming.
  • If your SCM is connected under Organization Settings > Integrations, Ona can open the PR directly.
Verification:
  • Check the PR on GitHub/GitLab. Verify the description, linked issues, and branch name match your conventions.

​
Review code

Use this when you want a second set of eyes before committing or creating a PR. Steps:
  1. Ask Ona to review your changes:
Review the changes in this environment. Focus on edge cases and security issues.
  1. For PR reviews, point Ona at the PR:
Review PR #123. Focus on architectural decisions and test coverage.
Context notes:
  • Ona reads the diff, existing tests, and AGENTS.md for project conventions.
  • For focused reviews, specify the area: “Focus on the database migration changes.”
Verification:
  • Apply fixes based on review feedback, then ask for a follow-up review to confirm issues are resolved.

​
Encode a reviewer’s style

Use this when you want to capture a specific engineer’s review approach and make it available to the team. Steps:
  1. Make sure your SCM is connected under Organization Settings > Integrations.
  2. Run this meta-prompt, replacing [REVIEWER_NAME] with the person’s name:
Analyze the pull request reviews from [REVIEWER_NAME] over the past 30 days. Focus on:

1. Review patterns and style:
   - What aspects of code does [REVIEWER_NAME] consistently examine?
   - What's their commenting style (direct, questioning, suggestive)?
   - How do they balance criticism with encouragement?

2. Technical focus areas:
   - Which code patterns do they frequently flag?
   - What performance or security concerns do they raise?
   - Which best practices do they enforce?

3. Common corrections and suggestions:
   - What mistakes does [REVIEWER_NAME] repeatedly catch?
   - What refactoring patterns do they suggest?
   - Which architectural principles do they advocate?

4. Values and priorities:
   - What non-functional requirements matter to them (readability, maintainability, performance)?
   - How do they weigh tradeoffs?
   - What makes them approve enthusiastically vs. reluctantly?

Transform these observations into a structured review prompt that captures [REVIEWER_NAME]'s review methodology. The prompt should guide an AI to review code with the same attention to detail, technical standards, and communication style.

Format the output as a prompt that begins with: "Review this code as [REVIEWER_NAME] would, focusing on..."
  1. Save the generated prompt as a /review-like-[name] skill under Settings > Agents.
Context notes:
  • This requires SCM integration so Ona can read the reviewer’s past PR comments.
  • The generated prompt works best when the reviewer has at least 10-15 reviews in the last 30 days.
Verification:
  • Run the new skill on a recent PR and compare its feedback to what the reviewer would actually say.

​
Generate a weekly digest

Use this when you want a summary of your team’s engineering activity. Steps:
  1. Run this prompt at the end of each week (or set it up as an automation):
Generate a focused weekly digest that gives the team actionable insight
into our software engineering activity.

Structure the digest as follows:

- Team Output and Productivity: Summarize total commits, merged pull
  requests, and notable achievements. Highlight metrics that reflect
  productivity, such as lead time for changes and the number of
  reviewed issues.
- Code Churn Focus: Identify the three files with the highest code
  churn this week (those with the largest combined lines added and
  removed). For each file, list:
    - The complete file path
    - Total lines changed (added plus removed)
    - A concise summary of the nature of the changes, inferred from
      commit messages
- Inconsistencies and new patterns: Find code patterns, library use
  and API definitions that are inconsistent with previous code.
- Shareable Output: Format the digest so it can be posted or forwarded.
  Use clear section headers and bullet points.

Also, give me a histogram of commits by author.
Note: we squash PRs when they land on main.
Context notes:
  • Ona reads git history and PR metadata from your connected SCM.
  • For monorepos, scope the digest: “Focus on the backend/ directory.”
Verification:
  • Spot-check a few entries against the actual PRs merged that week.

​
Measure agent adoption

Use this when you want to track how much of your codebase is being written with agent assistance. Steps:
  1. Run this prompt:
What's the percentage of commits with Ona contributions merged to main
in the last four weeks?
Give me a daily histogram and weekly average.
Beware that we squash commits when we merge to main.
Context notes:
  • Ona marks itself as a co-author on commits it contributes to. This prompt counts those co-authored commits.
Verification:
  • Cross-check a few commits manually with git log --format="%H %s" --grep="Co-authored-by: Ona".

​
Compare before vs after

Use this for design work and fine adjustments where you want a visual comparison of your changes. Steps:
  1. Make your changes first, then ask Ona to generate a comparison page:
Generate a standalone demo page that visually compares the Before vs
After state of my changes.

Requirements:
- Two side-by-side panels: Before and After
- Exact measurements labeled (e.g., old-value vs new-value)
- Visual rulers showing width/height differences where applicable
- Code snippets comparing old vs new implementation
- Technical Details section with Problem, Solution, and Benefits
- Responsive design for mobile viewing

Process:
1. Create the demo HTML page
2. Start a preview server for the demo HTML page
3. Report the URL of the preview server
Context notes:
  • Ona needs access to both the old and new state. If you haven’t committed the old state, Ona can use git diff to reconstruct it.
Verification:
  • Open the preview URL on both desktop and mobile to verify the comparison renders correctly.