← All posts

By Starlight Team ·

Tutorial · All levels

Prompt Engineering for Starlight

Starlight isn't a generic model with a wrapper - it has its own architecture, skill library, and multi-modal capabilities. This guide covers the techniques that get the most out of it, whether you're writing code, generating 3D models, or composing audio.

The basics: be specific, be direct

Starlight rewards clarity. Instead of 'help me with a function,' say 'write a TypeScript function that debounces another function with a configurable delay, defaulting to 300ms, with proper type generics.' The more constraints you give - language, types, defaults, edge cases - the less Starlight has to guess, and the closer the first response is to what you want. Vague prompts produce vague results. This is true for every modality, not just code.

Structuring complex requests

For multi-part tasks, structure your prompt with clear sections. State the goal, then list requirements, then add constraints. For example: 'Goal: Build a REST API endpoint for user registration. Requirements: validate email and password, hash the password with bcrypt, return a JWT token, handle duplicate email errors. Constraints: use Express.js, no external auth libraries, keep it under 80 lines.' This structure helps Starlight plan before it writes, especially in Agent mode where it breaks down complex goals into steps.

Four techniques that consistently help

These work across code, 3D, images, video, and audio.

Provide context

Paste your existing code, describe your project structure, or reference earlier parts of the conversation. Starlight uses context to match your style, avoid conflicts, and build on what's already there. Context is not optional for real projects.

Give examples

Show Starlight what you want by example. Paste a function with the style you like, an image with the aesthetic you're going for, or a sound clip with the vibe you want. One example often replaces three paragraphs of description.

State constraints explicitly

If you don't want frameworks, say so. If you need it under 50 lines, say so. If the output must be compatible with a specific version, say so. Constraints that are implied but not stated are constraints that get violated.

Iterate, don't restart

When the first response is close but not perfect, tell Starlight exactly what to change. 'Make the function async, add retry logic with exponential backoff, and rename the variable from data to payload.' Iterating preserves the good parts and fixes the rest. Starting over wastes the context you've built.

Leveraging the Skill Library

Starlight ships with 240+ deep skill documents - expert playbooks it loads when a task calls for them. You don't need to manually invoke skills; Starlight recognizes when a task needs specialized knowledge (game engines, shader authoring, character rigging, audio mixing, etc.) and loads the relevant skill automatically. But you can nudge it: 'Using your game engine skills, help me implement a third-person camera controller with collision avoidance in Unity.' Mentioning the domain helps Starlight pick the right skill faster.

Multi-modal prompting

Because Starlight handles code, 3D, images, video, and sound in one model, you can ask for multiple modalities in a single prompt. 'Build a small game where a fox collects fireflies at night - generate the 3D fox model with rigging, a night meadow environment, a fireflies sound loop, and write the gameplay code in Unity.' Starlight plans the whole thing, generates each asset, and wires them together. The key is to describe the final product, not each asset separately.

When to switch to Core for harder tasks

Pulse 1.1 is fast and handles most everyday prompts well. But for tasks that need deep reasoning - architecture design, complex algorithm implementation, multi-step agent goals, or hard debugging - switch to Core 1.1. You can switch mid-conversation without losing context. The signal to switch is when Pulse's response is good but you can tell it's missing a deeper insight, or when a task has many interdependent parts that need careful planning.

A good prompt doesn't describe what you want - it describes what you want, how you want it, what to avoid, and what done looks like.

Starlight Team

Start experimenting

The best way to learn prompt engineering is to try it. Open a conversation, pick a task, and apply these techniques. Iterate from there.