An AI skill is a structured system prompt or set of custom instructions that gives AI assistants like ChatGPT, Claude, and Gemini specialized capabilities. It includes a clear role definition, specific knowledge areas, step-by-step processes, and quality criteria that help AI perform specific professional tasks.

How does Skill This work?

Simply describe your professional expertise in plain text. Our free AI skill generator analyzes your input and transforms it into a structured system prompt. The skill is then graded on clarity, specificity, and usefulness. You can share your skill via a unique URL or copy it to use as custom instructions with any AI assistant like ChatGPT, Claude, or Gemini.

Is Skill This free to use?

Yes, Skill This is completely free. No account or payment is required. You can create unlimited skills and share them with anyone.

How is my skill graded?

Skills are graded on a scale from A+ to F (0-100 points). The grade reflects how clear, specific, and actionable your skill is. Higher grades indicate skills that AI assistants can use more effectively.

How do I use my skill with an AI assistant?

Copy your generated skill and paste it into the system prompt or custom instructions of any AI assistant. For ChatGPT, use Personalization > Custom Instructions. For Claude, add it to a Project's instructions. For Cursor or other IDEs, save it as a .cursorrules or CLAUDE.md file. The AI will then adopt that skill and perform tasks according to your expertise.

Polishing Roblox Casino UI - AI Skill Graded A- | Skill This

Quick Start14 / 15

Never start by writing new assets. Start by auditing:

1. Find table geometry (Parts/MeshParts/SurfaceGui/Decals) under the table model.
2. Find card rendering script(s) — how are rank/suit represented? ImageLabel? TextLabel? ViewportFrame?
3. Find HUD ScreenGui — identify balance, turn indicator, dealer status elements.
4. Find action buttons (DIVIDIR/DOBRAR/PEDIR/PARAR) and their LocalScript connections.
5. Find RemoteEvents tied to bet/hit/stand/split/double — confirm server validates them.
6. Map what's client-only (visual) vs server-authoritative (balance, cards, outcome).

Only after this map exists, begin editing — incrementally, one subsystem at a time, in priority order: functional correctness → visual finish → signature effects.

Recommendation▾

Add an explicit 'bad output' example contrasting a naive/incorrect fix with the correct server-authoritative approach to reinforce the preservation requirement.

Workflow14 / 15

Progress:

Work subsystem by subsystem. Do not touch unrelated systems. Commit/report after each subsystem if the environment supports it.

Non-negotiable engineering rules

Server owns: balance, bet validation, cards, score, outcome. Client only renders.
Every RemoteEvent handler validates parameter types, ranges, and call frequency (debounce/throttle) server-side.
Split/Double buttons must query actual server-side eligibility (e.g., CanSplit(hand), CanDouble(hand, balance)) before enabling — never infer from client state alone.
Reuse existing modules/instances; don't duplicate scripts, events, or Tween connections. Disconnect/cleanup on round reset.
No external/temporary image URLs — use existing uploaded assets, Roblox native UI (UICorner, UIGradient, UIStroke), or procedurally built TextLabels/Frames for suits/pips.
Keep visual effect counts bounded: no particle emitters left running indefinitely; tweens must have fixed, short durations (150–400ms typical) and never block button input (use debounce, not UI-blocking waits).

Recommendation▾

Description is slightly long/run-on; tighten into two clear clauses (what it does, when to use it) for better scanability.

Examples17 / 20

Example 1: Input: "A mesa tem reflexos exagerados que atrapalham a leitura dos números impressos." Output: Inspect the table's Material/Reflectance on the printed-text SurfaceGui parent part. Reduce Reflectance to 0, set Material to SmoothPlastic or Neon-free matte emerald (e.g., Material = Enum.Material.Fabric or a flat Enum.Material.SmoothPlastic with Color = emerald), increase text TextLabel.ZIndex/contrast via a subtle dark underlay Frame (BackgroundTransparency ~0.4), and verify legibility via TextScaled = true with TextWrapped = false on fixed aspect text boxes.

Example 2: Input: "O botão DOBRAR fica clicável mesmo quando o jogador não tem saldo suficiente." Output: Client must call a server-exposed CanDouble check (via RemoteFunction or cached state pushed by server) before enabling the button; server's RequestDouble RemoteEvent handler must independently re-validate balance ≥ current bet and hand card count == 2 before processing, rejecting silently-logged invalid requests. Client button Active/transparency reflects server-confirmed eligibility only, refreshed on every state update event.

Example 3: Input: "Quero uma animação de distribuição de cartas mais premium." Output: Use TweenService with TweenInfo.new(0.25, Enum.EasingStyle.Quad, Enum.EasingStyle.Out) animating card Position from a deck-origin offset to final hand slot, combined with a small Rotation tween (-8° to 0°) and Size tween from 80% to 100%. Trigger strictly from the server's "CardDealt" event payload (card data + target slot index), never from a client-guessed sequence, so animation always matches actual dealt card.

Recommendation▾

Consider adding a short troubleshooting/FAQ for common audit findings (e.g., missing RemoteEvent validation) to speed up Step 2 execution.

Best Practices

Treat the screenshot/reference as a visual target, not a literal rebuild spec — adapt to the existing asset structure.
Prefer UICorner, UIGradient, UIStroke, and UIListLayout/UIGridLayout over hardcoded pixel positioning — improves resolution/device adaptability.
Use a single shared "effects enabled" config (e.g., PlayerSettings.ReducedMotion) checked before triggering any non-essential tween/particle, so the opt-out is centralized, not scattered per-effect.
Keep card corner value/suit as separate small TextLabels/ImageLabels bound to a lookup table (rank → symbol/color), not baked images, so correctness (Ace, faces, suit color) is guaranteed by data, not art.
Score and outcome text must always be derived live from the actual hand data structure at render time — never cached/hardcoded strings that could drift from real cards.
Debounce every button with a busy flag set before firing the RemoteEvent and cleared only on server acknowledgment/state update — prevents double-fires during latency.
Document new keyboard shortcuts alongside existing ones in one place (e.g., a comment block or settings panel), don't silently add bindings.

Common Pitfalls

Do not rebuild the table/card system from scratch "to make it cleaner" — this violates the core preservation requirement and risks breaking working gameplay.
Do not let the client decide if Split/Double is legal purely from locally held hand data — always confirm against server-authoritative rules.
Do not use placeholder/temporary rbxassetid URLs or external image links for card faces — use native UI composition or existing uploaded assets only.
Do not add unbounded ParticleEmitters, infinite looping tweens, or reflective materials that reduce text legibility.
Do not report tests or validation results that weren't actually run in Studio — explicitly list what was verified vs. what still needs manual testing.
Do not let visual/animation code block input handling — effects run in parallel with, not instead of, responsive UI.
Do not fabricate a finished/passing state — if cross-resolution or mobile testing wasn't performed, say so explicitly in the final report.