When you start with Antigravity, Skills look like simple Markdown files with instructions. But the YAML frontmatter hides fields that completely change how the agent runs each task: from which model it uses to how many tools it can invoke or how many turns it can take before stopping. I've been testing these fields in real projects and I'm going to explain what each one does and when to use it.

## Structure of a SKILL

A Skill is a directory containing a `SKILL.md` file. The file has two parts:

1. **YAML Frontmatter**: metadata and execution parameters
2. **Markdown body**: instructions, workflows and verification criteria

The Antigravity engine reads the frontmatter first to decide whether that Skill matches the user's intent. Only when activated does it load the full body. This matters for the best practices we'll cover at the end.

```yaml
---
name: webperf-lcp-audit
description: Audits the LCP of a page by analyzing the candidate element, its load time and the resources blocking it. Generates a report with regressions found and prioritized improvement proposals.
kind: subagent
model: gemini-2.5-pro
temperature: 0.2
max_turns: 15
tools:
  - run_command
  - view_file
  - write_to_file
  - mcp_chrome-devtools/*
---
```

Important: `name` and `description` are the only fields in the [open Agent Skills standard](https://agentskills.io/specification). The `kind`, `model`, `temperature`, `max_turns` and `tools` fields are Antigravity-native extensions, with no official public documentation yet. Fields not recognized by other agents (Claude Code, Cursor, etc.) are silently ignored, so you can share the same Skills across multi-agent environments without adapting them.

## `kind`: how the Skill runs

The `kind` field defines the execution mode within the agent architecture.

- **`inline`**: the Skill is loaded directly into the main agent's context, sharing all its tools and conversation history.
- **`subagent`**: an isolated agent is spawned in the background, dedicated exclusively to that task. The main agent's context stays clean.
- **`workflow`**: indicates that the Skill defines a structured multi-step flow.

<figure>
  <iframe
    id="ag-kind-demo"
    src="/demos/antigravity-kind-diagram-en.html"
    width="100%"
    height="340"
    style="border: none; border-radius: 8px; display: block;"
    title="Comparative diagram of the three execution modes: inline, subagent and workflow"
    loading="lazy"
  ></iframe>
</figure>
<script>
window.addEventListener('message', function(ev) {
  if (ev.data && typeof ev.data.agKindH === 'number') {
    var f = document.getElementById('ag-kind-demo');
    if (f) f.style.height = (ev.data.agKindH + 24) + 'px';
  }
});
</script>

Use `subagent` for complex, bounded tasks: performance analysis, large refactors, log processing. Use `inline` for lightweight or cross-cutting tasks like style guides or Git shortcuts.

## `tools`: least privilege

Explicitly defines which tools or MCP servers the agent can use during that Skill.

<figure>
  <iframe
    id="ag-tools-demo"
    src="/demos/antigravity-tools-diagram-en.html"
    width="100%"
    height="340"
    style="border: none; border-radius: 8px; display: block;"
    title="Comparative diagram: agent without declared tools vs with restricted tools"
    loading="lazy"
  ></iframe>
</figure>
<script>
window.addEventListener('message', function(ev) {
  if (ev.data && typeof ev.data.agToolsH === 'number') {
    var f = document.getElementById('ag-tools-demo');
    if (f) f.style.height = (ev.data.agToolsH + 24) + 'px';
  }
});
</script>

There are three reasons to restrict tools:

### Security (least privilege)

A code review Skill doesn't need `run_command` or `write_to_file`. If you don't declare them, the agent can't use them even if they're available in the session.

### Token optimization

The system includes the JSON schema for each tool in the prompt. Sending dozens of MCP tool descriptions on every call wastes tokens. Restricting them reduces latency and cost.

### Fewer hallucinations

The model can't try to solve a task with the wrong tool if you only expose the right ones for that Skill.

## `model`: the right model for each task

Overrides the session model for that specific Skill. The rule is simple:

```yaml
# Mechanical, iterative or low-complexity tasks
model: gemini-3.5-flash

# High cognitive-value tasks
model: gemini-2.5-pro
```

**Flash** for writing boilerplate, formatting Markdown, simple Git tasks or information pre-filtering. **Pro** for debugging performance regressions, LCP or INP analysis, refactoring critical logic or Core Web Vitals audits.

There's no point using the most powerful model every time. Choosing the right model for each task optimizes the project budget without sacrificing quality where it matters most.

## `temperature`: determinism vs. creativity

Modulates response randomness. Range from `0.0` to `2.0`.

```yaml
# Analytical tasks: maximum determinism
temperature: 0.2

# Creative tasks: more variability
temperature: 0.8
```

Low temperatures (`0.0`–`0.3`) for refactoring, waterfall analysis, monitoring script generation or debugging. You need consistency and zero creative deviations.

High temperatures (`0.7`–`1.0`) for ideation, interface design, architecture brainstorming or writing descriptive documentation.

## `max_turns`: avoiding infinite loops

Defines the maximum number of interactions (think → call tool → receive output) the agent can perform.

```yaml
# Quick check Skill (e.g. verifying a cache header)
max_turns: 5

# Full Core Web Vitals audit with resource analysis and proposals
max_turns: 30
```

In automated tasks, an agent can get stuck trying to optimize an image that's actually blocked by a load priority issue. Without `max_turns`, it will consume resources indefinitely. With the limit, it stops and surfaces the issue.

A typical production setting is `max_turns: 15` or `20` for medium-complexity Skills.

## Best practices for designing Skills

### Lightweight and informative frontmatter

Antigravity's router matches intents based on `name` and `description`. The full body is only loaded when the Skill is activated, so the frontmatter must be precise enough for matching without unnecessarily bloating the context.

### Precise descriptions

The `description` field should detail when and why the Skill is useful. The name alone isn't enough:

```yaml
# ❌ Too generic
description: Reviews web accessibility.

# ✅ Precise and actionable
description: Activate when you need to audit WCAG 2.1 AA accessibility issues in React components: contrast, ARIA roles, keyboard navigation and focus order.
```

### Combine `tools` with scope instructions

You can combine the YAML tool restriction with Markdown instructions that specify which workspace directories the agent can operate on. A double layer of restriction.

## Where to install Skills

Skills are installed in different directories depending on the _"surface"_ (the client you use Antigravity from: CLI, desktop app or IDE extension):

| Surface   | Global                              | Project                     |
| --------- | ----------------------------------- | --------------------------- |
| CLI       | `~/.gemini/antigravity-cli/skills/` | `<project>/.agent/skills/`  |
| App / IDE | `~/.agents/skills/`                 | `<project>/.agents/skills/` |

The frontmatter field behavior is identical across all three surfaces. Only the installation directory changes.

## Conclusion

The five Antigravity extended fields (`kind`, `tools`, `model`, `temperature`, `max_turns`) aren't optional details: they're the controls that determine the efficiency, security and cost of each Skill. The combination with the most practical impact is `kind: subagent` + restricted `tools` + `model` tuned to task complexity. With those three fields properly configured, Skills go from Markdown instructions to agents with predictable behavior and controlled budget.