# Qpilot Ask AI Skill File Guide: UI Rule Checks | Pcloudy Docs Last updated on : 30 Oct 2026 ## Overview ### What is a skill file? A skill file is a small zip that gives Ask AI the rules it needs to judge a screen. Think of it as a checklist written by an expert. Ask AI reads the checklist, looks at your screenshot, and checks the screen against each rule. #### Why use one Without a skill file, you have to type every rule into the prompt each time, and the answer can be shallow. With a skill file, the prompt stays short and generic, for example "check this screen against the attached skill". The skill file supplies the rules, so the answers are more detailed and consistent. You can reuse the same skill file across many tests. [Download the Skill file Here](https://www.pcloudy.com/docs/img/qpilot_skills_mobile_web.zip) #### What you get back Ask AI gives one overall verdict, plus a short reason for each rule based on what it saw on screen. It judges from one screenshot only, so anything that needs a tap, a keyboard or a screen reader is not covered. | Verdict | What it Means | | ------- | ---------------------------------------------------------------------------------- | | PASS | Every rule it could check passed. | | WARN | Only minor rules failed. Worth fixing, but not blocking. | | FAIL | A major or critical rule failed. | | N/A | The rule can't be judged from the screenshot, so it is skipped instead of guessed. | Each rule also has a severity: critical (safety, legal or money risk), major (a real defect) or minor (polish). #### Skill file vs context file The Ask AI step has a second field, Context File. It does a different job. * [Skill file (.zip)](https://www.pcloudy.com/docs/img/qpilot_skills_mobile_web.zip): rules that teach the AI how to judge. Reusable across many tests. * Context file: reference material to compare against, such as an API response or a spec. Usually used for one test. #### How to use one 1. Add an Ask AI step to your test. 2. Upload the skill zip in the Skill File field. 3. Keep Capture Screenshot switched on. 4. Enter a prompts in evaluate the current screen based on the skill file rules #### Quick reference | Skill | Platforms | Best Screen to Test | | ----------------------- | ------------ | ----------------------------------------------------------- | | WCAG (accessibility) | Android, Web | Dashboard or form with icons, text and links | | E-commerce | Android, Web | Cart or checkout summary | | Healthcare | Android, Web | Medication list with an allergy banner | | PCI-DSS (card payments) | Android, Web | Add-card page or saved cards (web: show the address bar) | | Material Design 3 | Android, Web | Home or settings page with top bar, button, FAB, navigation | | Apple HIG | iOS only | Detail screen with a title bar and bottom tabs | ### 1. WCAG — Accessibility Checks that people with low vision, motor or reading difficulties can use the screen. #### What it checks * Text and icons are easy to read against the background (colour contrast) * Buttons are big enough to tap or click * Icon-only buttons have a text label * Meaning is not shown by colour alone (for example, a red-only amount) * Web only: links stand out from normal text, and form fields keep their labels * Mobile only: nothing is hidden behind the notch or home bar #### Best screen to test * Mobile: A dashboard or form with icons, text and a coloured amount * Web: A signup or login page with a link and a form #### Sample prompts MOBILE Audit this mobile screen against the attached WCAG mobile skill. List only FAILED rules: [id] severity — evidence. One line each. No passes, no preamble. WEB Audit this web page against the attached WCAG web skill. List only FAILED rules: [id] severity — evidence. One line each. No passes, no preamble. Watch out: Image alt text and keyboard order can't be seen in a screenshot. Check those separately. ### 2. E-commerce Checks that the cart and checkout numbers are correct, like a shopper or an auditor would. * What it checks * Items, discount, tax and shipping add up to the total shown * The discount makes sense, and the total is never negative * A crossed-out price is higher than the sale price * Out-of-stock items are clearly marked * Mobile: the checkout button is easy to reach. * Web: the order summary lists each charge #### Best screen to test * Mobile: The cart or checkout summary * Web: The cart or checkout page with the order summary #### Sample prompts MOBILE Check this mobile cart against the attached e-commerce skill: recompute the total and flag mismatches. List only FAILED rules: [id] severity — evidence. One line each. WEB Check this web cart against the attached e-commerce skill: recompute the total and flag mismatches. List only FAILED rules: [id] severity — evidence. One line each. Watch out: A product page has no total to add up, so most rules will come back N/A. Use the cart, not the product page. ### 3. Healthcare Checks that a health screen is safe to read and does not expose private patient data. #### What it checks * Doses show a number, a unit and how often (for example, 0.5 mg twice daily) * Doses are written safely: 0.5 mg, not .5 mg, and 5 mg, not 5.0 mg * Allergy warnings stand out * Private details like SSN or full date of birth are not shown more than needed * Units such as kg or mmHg are always labelled * Web only: print and export buttons don't expose patient data #### Best screen to test * Mobile: A medication list, or a screen with an allergy banner * Web: A patient summary showing medications, allergies and the patient header together #### Sample prompts MOBILE Audit this mobile clinical screen against the attached healthcare skill (dosage, allergy, PHI). List only FAILED rules: [id] severity — evidence. One line each. WEB Audit this web portal against the attached healthcare skill (dosage, allergy, PHI). List only FAILED rules: [id] severity — evidence. One line each. Watch out: An empty patient record ("no data to display") makes almost every rule N/A. Pick a patient who has a medication or allergy. ### 4. PCI-DSS — Card payments Checks that a payment screen handles card details the way payment-security rules expect. ### What it checks * The full card number is never shown (only the last 4 digits) * The CVV (3-digit security code) is not shown and cannot be saved * A lock or "secure payment" badge is on the card-entry screen * Saved cards show only the brand and last 4 digits * Web only: no card details appear in the web address #### Best screen to test * Mobile: The add-card form, or a wallet that lists saved cards * Web: The card-entry page, with the browser address bar visible in the screenshot #### Sample prompts MOBILE Audit this mobile payment screen against the attached PCI skill (PAN/CVV/secure badge). List only FAILED rules: [id] severity — evidence. One line each. WEB Audit this web payment page against the attached PCI skill (PAN/CVV/URL/secure badge). List only FAILED rules: [id] severity — evidence. One line each. Watch out: An empty card-number field on an entry form is normal, not a failure. Card masking is checked on saved-card screens. ### 5. Material Design 3 Checks that a screen follows Google's Material Design 3 look and layout rules. #### What it checks * One main button per screen, with other actions less prominent * At most one floating action button (FAB), at the bottom right * Even spacing, with shadows and rounded corners used consistently * Text is readable on coloured backgrounds * Android: a clear top bar and a labelled bottom navigation. Web: a sensible menu (side rail, drawer or top bar) #### Best screen to test * Android: A home or settings screen showing a top bar, a main button, a FAB and bottom navigation * Web: A settings or form page built with Material components #### Sample prompts ANDROID Audit this Android screen against the attached Material 3 mobile skill. List only FAILED rules: [id] severity — evidence. One line each. No passes. WEB Audit this web screen against the attached Material 3 web skill. List only FAILED rules: [id] severity — evidence. One line each. No passes. Watch out: Don't use it on iOS screens. Press effects and animations need a tap, so a screenshot can't judge them. ### 6. Apple HIG — iOS Checks that an iPhone screen follows Apple's Human Interface Guidelines. There is no web version. #### What it checks * Nothing is hidden behind the notch, Dynamic Island or home bar (the "safe area") * Buttons are at least 44 points in size * Pushed screens have a title and a back button * The bottom tab bar has 2–5 tabs, each with a label * Pop-up sheets show a way to close them #### Best screen to test * iOS: A detail screen opened from a list, with a title bar and bottom tabs #### Sample prompt iOS Audit this iOS screen against the attached HIG skill. List only FAILED rules: [id] severity — evidence. One line each. No passes, no preamble. Watch out: Include the status bar and the bottom home bar in the screenshot, or the safe-area rule can't be checked. Swipe-back and dark mode need a tap. ### Tips for prompts Every sample prompt above returns a short answer: the verdict plus only the failed rules, one line each. Want every rule listed, pass or fail? Replace "List only FAILED rules: [id] severity — evidence. One line each." with the line below. List all rules, one line each: [id] PASS/FAIL/N/A — brief evidence. End with the overall VERDICT. [id] is the rule's short name, for example WCAGM-CONTRAST-TEXT.