Customize

Overview

Teach Swiftask Code how your team works and set defaults for approvals.

Open Swiftask Settings from the gear icon in the Sessions panel title bar.

Prerequisites

• Swiftask Code installed and signed in
• Access to Swiftask Settings (gear icon in the Sessions panel title bar)

Step-by-step guide

1. Set up project rules

Rules are instructions Swiftask Code follows in every chat — coding style, architecture boundaries, checks before finishing work.

Shared rules (team) — stored in your project (typically in a .swiftask/rules folder). Commit them to git so everyone gets the same behavior.

When to use: Team conventions, architecture boundaries, required checks before merge.

Personal rules (just you) — stored on your machine for that project. Good for preferences that shouldn't go in the repo.

When to use: Personal formatting prefs, local tooling paths, experimental instructions.

If two rules conflict, the more specific one wins. What you write in the chat always overrides rules.

2. Create a rule with AI

In Settings → Rules, use Create with agent. Describe what you want in plain language; Swiftask Code drafts a rule file you can edit and save.

3. Configure permissions

Settings → Permissions

See Build, plan & review for how approvals feel in daily use.

4. Adjust per-session choices

These are set in the chat input, not in Settings:

• Model — which AI to use
• Mode — Build / Ask / Plan
• Thinking level — low / medium / high

They apply to the current session only.

5. Open VS Code settings & docs

From Settings you can also:

• Open VS Code settings (fonts, tabs, editor preferences)
• Open documentation (this Help Center)

Practical use cases

TypeScript project:

Use strict typing. Run the type checker after changes to .ts files.

Frontend team:

New UI components follow our folder naming convention and use our design system.

Security:

Never commit secrets, API keys, or .env files.

Tips & best practices

Rule conflicts: if two rules conflict, the more specific one wins. What you write in the chat always overrides rules.

Trusted commands examples:

Add only commands your team runs routinely. Destructive commands (rm, git push --force) should stay off the list.

Additional resources

• Build, plan & review — put rules into practice
• Account & workspace — workspace and models
• Help & FAQ — settings not applying