Studio Settings

Documentation Index

Fetch the complete documentation index at: https://docs.frontic.com/llms.txt

Use this file to discover all available pages before exploring further.

Studio Settings is where you configure defaults that apply to every job in your project — the system prompt the Studio chat uses, the rules it always follows, and the GitHub connection. Find it at Studio → Settings in the admin app. Settings are scoped to the Frontic project, so every teammate working on the same project sees the same defaults.

​

What’s in Studio Settings

​

Studio Prompt

The Studio Prompt is a project-specific supplement to Studio’s built-in system prompt. Studio already ships with a senior-level e-commerce consultant persona, tool knowledge, verification habits, and delegation patterns. What the base prompt can’t know is your specific project: what you sell, how your team works with agents, and how replies should land in chat. A good default Studio Prompt covers:

• Business context — what the project sells and who it’s for. “Acme is a DTC performance-footwear brand selling running shoes and apparel to runners in North America.” Anchors the agent’s tone, feature priorities, and design calls.
• Working style — how the agent should operate alongside your team. “Check in before wide-reaching changes; prefer small, verifiable steps; ask rather than guess when scope is unclear.”
• Response style — how the agent should talk in chat. “Keep answers short. Assume senior-level context; skip re-explaining basics.”

Keep it short — a handful of lines. The base Studio prompt is already substantial; adding more dilutes the project-specific signal. Don’t put here:

• Frontend stack (framework, language, design system) → Context Rules. These apply across every agent surface and every workspace.
• Naming conventions, commit format, architectural guardrails, brand voice applied to generated output → Context Rules.
• Reusable task patterns (“how to add a locale”, “how to build a category page”) → Context Base Skills.
• Pointers to the Context Base — it’s synced into every workspace automatically; the agent already has it.

​

Project Rules

Project Rules are a single rules document Studio loads on every task — always applied, no targeting. Use Project Rules for constraints that only make sense in this project: repository layout quirks, one-off architectural calls, project-only commit conventions. When a rule would also belong on other projects, write it as a Context Rule instead.

​

Context vs. Project Rules

Both live at the project level and both shape Studio’s behavior on every task. They differ in structure and in how precisely you can target them: Both also reach any local IDE agent connected to this project via the Frontic CLI — same behavior there as in Studio.

​

Settings scope

One thing to note: Studio Settings are per-project, not per-user. Everyone on your team sees the same prompt, the same rules, the same GitHub connection. This is intentional:

• It keeps the team’s agent experience consistent — one person doesn’t accidentally use different rules from another
• It keeps GitHub access centrally managed — no shadow integrations tied to individual accounts
• It matches how the Context Base works (also per-project)

If you need per-user customization like prompt preferences or personal shortcuts, use the chat itself — mention your preferences in the job prompt. Settings are for project-wide defaults.

​

GitHub Integration

Studio Settings holds the optional GitHub OAuth connection for the project. The connection powers production shipping across every workspace; Studio works without it too (you just skip this section). The repository each job targets is picked in the Create Job dialog, not here. See GitHub Integration for the setup walkthrough, commit mechanics, PR flow, and troubleshooting.

​

Related