Skip to main content
Your best engineers have prompts that work - ways of reviewing code, writing tests, or debugging issues that they’ve refined over time. Skills let you capture that expertise and share it with everyone. Skills are reusable prompts that the agent can discover and use proactively when relevant. They can optionally be made available as slash commands, so users can also invoke them manually by typing / in the chat.
Ona Agent chat showing slash command autocomplete for the code-review-docs skill

​
Why this matters

Without shared skills, quality varies. One developer’s code review catches security issues; another’s misses them. One person knows how to write tests that actually test behavior; others write tests that only hit coverage targets. With skills:
  • Expertise scales: A senior engineer’s review checklist becomes available to the whole team
  • Quality standardizes: Everyone follows the same thorough process
  • Onboarding accelerates: New team members immediately have access to proven workflows
  • Agents get smarter: Skills are discoverable by the agent, so it can apply them proactively without being asked

​
What a great skill looks like

Here’s a real example - a code review skill that captures one engineer’s review philosophy: 
/review-like-mads

You are reviewing code changes with Mads Hartmann's perspective. Apply his review philosophy systematically:

## Design System First
- **Theme compatibility**: Works in light/dark AND old/new themes?
- **Semantic tokens**: Replace hardcoded colors with `border-subtle`, `surface-glass`
- **Visual evidence**: Request screenshots/videos if missing
- **Design alignment**: Matches Figma specs?

## Aggressive Cleanup
- **Remove unused**: Components, imports, files, commented code
- **Consolidate**: Similar components that could be unified
- **File organization**: Components in right locations?

## Technical Excellence
- **React patterns**: Proper `forwardRef`, `useImperativeHandle`, TypeScript
- **Component reuse**: Composing existing vs creating new
- **Accessibility**: ARIA, keyboard nav, screen readers

## Red Flags
- Hardcoded colors (`#fff`, `rgb()`)
- Duplicate patterns
- Missing visual docs
- Poor TypeScript

**Priority order**: Design system consistency → Code cleanliness → Component reusability → Technical implementation → Test coverage
Now anyone can type /review-like-mads and get a review with that level of rigor. The agent can also apply this skill on its own when it detects a code review task.

​
More examples

SkillWhat it codifies
/security-reviewYour security team’s checklist for reviewing PRs
/write-testsHow your team writes tests that actually catch bugs
/explain-thisYour standard for documentation and code explanation
/debug-strategyYour senior engineer’s approach to debugging
/deploy-checklistEverything to verify before shipping

​
Create your first skill

  1. Go to Settings > Agents
  2. Click New Skill
  3. Configure:
    • Name: What appears in the skill list (e.g., “Review like Mads”)
    • Description: When to use it
    • Prompt: The full prompt text
    • Available as slash command: Toggle on if you want users to invoke it with a /trigger
    • Command trigger: The slash trigger (e.g., review-like-mads). Only shown when the slash command toggle is on
  4. Click Create Skill
Ona settings interface for creating a new skill with name, description, prompt, and optional slash command trigger

​
Using skills

Skills work in two ways:
  1. Proactive discovery: The agent automatically discovers skills and applies them when a task matches. No user action needed.
  2. Slash commands: For skills with a command trigger, type / in Ona Agent to see available commands. Start typing to filter, then select with arrow keys or click.
You can add context after a slash command: 
/review-like-mads

Focus especially on the authentication changes in src/auth/
Ona Agent combines the skill’s prompt with the additional context you provide.

​
Migrating legacy commands

Existing slash commands created before skills were introduced appear as Legacy Commands in the settings page. They continue to work as before, but won’t be discovered proactively by the agent. To migrate a legacy command to a skill, click Edit on the command card and use the Migrate to Skill button in the banner. Migration preserves the slash command trigger while enabling proactive discovery.

​
Tips for good skills

Capture real expertise: Base skills on how your best people actually work, not theoretical ideals. Be specific: “Security Review” is better than “Review”. Include the actual checklist, not “check for security issues.” Include priorities: Tell agents what matters most. “Focus on X before Y” helps them make tradeoffs. Update over time: When someone catches something your skill missed, add it to the prompt.

​
Example skills we use at Ona

These are real skills from our own workflow. They show what a well-structured skill looks like at scale.
Automates the full PR lifecycle from diff to merge-ready. The skill:
  1. Cleans up code and runs formatters/linters
  2. Detects linked Linear issues automatically from branch names
  3. Creates a branch using your initials and a short description
  4. Commits with Conventional Commits format
  5. Opens a draft PR using your repo’s PR template
  6. Auto-categorizes for the changelog (feature, improvement, fix, or skip)
  7. Cross-references documentation and runs a docs content review
  8. Posts a summary and asks for changelog confirmation
The skill handles edge cases like feature-flag detection (auto-skips changelog for flagged work), in-progress feature detection across related PRs, and separate docs PRs when code changes need documentation updates.
PR workflow skill that gathers context, reads diffs, posts comments, and submits reviews. The skill:
  1. Gathers PR metadata, diffs, existing reviews, and CI status
  2. Fetches context from Linear (linked issues), GitHub (discussions), and Notion (design docs)
  3. Delegates code quality analysis to a separate review skill that detects scope (backend Go, frontend React/TS, or mixed) and loads the appropriate checklist
  4. Classifies findings by severity: [P0] Must fix, [P1] Should fix, [P2] Suggestion
  5. Posts inline comments on specific lines with actionable fixes
  6. Submits formal PR reviews (approve, request changes, or comment) via the GitHub API
  7. Runs documentation review and product principles checks on frontend PRs
  8. Auto-applies changelog labels if missing
Generates changelog entries from merged PRs in two modes: weekly (default) and major (standalone feature launch page).For weekly changelogs, the skill:
  1. Finds the boundary using git tags from the previous changelog run
  2. Collects all merged PRs since the boundary via GitHub
  3. Classifies each PR as New, Improvement, Bug fix, or Skip using labels, commit types, and LLM analysis
  4. Filters out internal-only changes, feature-flagged work, and infrastructure PRs
  5. Picks a headline feature and generates a 2-4 sentence description
  6. Produces a Mintlify Update block with the headline, screenshot placeholder, and collapsible accordion sections
  7. Opens a draft PR with the entry
All prose follows the technical-writing and blog-writing skill rules. The skill bans internal jargon (like “management plane”, “Ent schema”, “orchestrator”) and rewrites everything from the user’s perspective.
Finds flaky Go tests and CI build failures on main, diagnoses root causes, fixes what’s mechanical, and raises individual PRs per fix. The skill:
  1. Queries Honeycomb for Go test failures on main (last 24h and 7d trend)
  2. Queries Honeycomb and GitHub Actions for CI build failures
  3. Triages and ranks failures by frequency, impact, and fixability
  4. For each flaky test, diagnoses the root cause (race conditions, shared state, non-deterministic ordering, testcontainer lifecycle, etc.)
  5. Applies mechanical fixes under 20 lines, only proceeding when the root cause is clear
  6. Runs the full test package 3 times with -race to verify stability
  7. Opens individual ready-for-review PRs with re-run evidence
The skill follows a strict confidence gate: if the fix exceeds 20 lines, changes test semantics, or has an unclear root cause, it skips and logs the reason.
A style guide that ensures consistent tone and structure across all developer-facing content. Key principles:
  • Bottom line up front: If the reader stops after the first paragraph, they should have what they need
  • Show, don’t tell: Prefer code examples over explanations, prompts over tutorials
  • Diataxis classification: Every page belongs to exactly one type (tutorial, how-to guide, reference, or explanation)
  • Verify against source code: Every claim must match the current code. When docs and code disagree, the code is right
  • Agent-ready: Write docs that work as context for coding agents. Structure content so an agent can find the right page, extract the answer, and act on it
The skill includes a review checklist covering Diataxis type, code verification, link checking, heading quality, tier labeling, and messaging anti-patterns.
Query distributed tracing data across production, CI, and development environments. The skill documents:
  • Production datasets: Backend API traces, EC2/GCP runner traces, and supervisor (in-environment) traces
  • CI datasets: GitHub Actions workflow traces (via Thoth), Leeway build traces with Go test results
  • Key columns: Environment IDs, organization IDs, RPC error codes, startup durations, test results, cache status
  • Example queries: Environment startup duration, slowest RPC endpoints, failed builds, flaky test detection, supervisor setup times
The skill also includes instructions for constructing direct Honeycomb URLs so users can explore interactively, and documents gotchas like the attribute split across parent/child spans for startup traces.

​
Next steps