Ask Certyn Skills
How Certyn uses reusable, multi-step procedures (skills) to answer judgment questions like release readiness and failure triage — and how to add your own.
Some questions aren't a single lookup — they're a procedure. "Are we ready to release?" means checking failures, open bugs, flaky noise, trends, and production errors, then weighing them. Skills capture those procedures so Certyn follows a consistent, team-defined method instead of improvising.
A skill is a short markdown playbook with a name, a description, and step-by-step instructions. Certyn sees a catalog of available skills in every conversation and loads the full steps on demand — so procedures stay out of the always-on prompt and only cost tokens when they're actually needed.
You don't call skills — Certyn does
Just ask in plain language ("what's blocking a prod release?", "why did this run fail?"). Certyn matches the request to a skill, loads it, and runs its steps with the tools it already has (test results, issues, flaky scores, trackers, Sentry). You see the result, not the plumbing.
Built-in skills
| Skill | Ask it… | What it does |
|---|---|---|
| Release Readiness | "Are we ready to ship staging?" | Scopes the release, checks freshness, gathers failures + open bugs + flaky + trend + trackers + Sentry, then returns a ranked blocker list and verdict. Applies your wiki Definition of Ready. |
| Failure Triage | "Why did this run fail?" | Decides real vs. flaky first, forms a root-cause hypothesis, correlates with Sentry, dedups against existing tickets, and recommends severity/owner. |
| Sentry Incident Correlation | "Is this production error a known bug?" | Takes a Sentry issue and classifies it covered / known / new regression, checks test coverage, and recommends a repro test or ticket link. |
These compose: Release Readiness hands off to Failure Triage to qualify a single failure, and to Sentry Incident Correlation to understand an error spike.
Advisory, not autonomous
Skills in chat are read-only and suggest-don't-act. Certyn gathers evidence and recommends — it won't change ticket status, severity, or anything in your trackers or Sentry. You make the call.
Where policy lives
Skills are the method; your policy lives in the project wiki. The Release Readiness skill, for example, reads your Definition of Ready from the wiki and applies it. Keep the policy short and structured in the wiki (see Assessing Release Readiness); the skill knows how to execute it.
Author your own skill
Teams can add custom skills (e.g. a triage procedure specific to your stack). A skill is just markdown with frontmatter:
---
name: Checkout Incident Triage
description: How we triage checkout failures — payment provider, cart state, then session.
---
# Checkout Incident Triage
Use this when a checkout test fails or a checkout error spikes.
## Procedure
1. Check the payment provider status and recent config changes.
2. Inspect cart/session state in the failing execution.
3. Correlate with Sentry errors on the /checkout routes.
4. Recommend: provider issue, our bug, or test/data problem.
To make a skill available to Ask Certyn (rather than the test-execution agent), tag it advisor. Built-in skills are restored or updated for your workspace with:
POST /api/skills/defaults/restore
Skills become automation later
A skill written for chat today is the same procedure you can trigger automatically tomorrow — e.g. run Failure Triage when a test fails, or Release Readiness when an environment's version changes. Write the method once; point an event at it when you're ready.