Antigravity Skill Architect

Module 01

The DDS Production Pipeline

I will teach the general concepts in Modules 02 through 07. But I lead with how I actually do it, because the specific pipeline is more useful than the theory.

How a class gets built

1. Brief. I write a task brief: the class title, handle, metadata, topic coverage, voice gate reference, SEO Magnet V3 compliance requirements, cross-link verification list, and a list of every gate the output must pass. The brief is typically 200-400 lines. It is the acceptance criteria for the entire build.
2. Research gate. The agent web-researches current facts. Every statistic must be attributable to a named source. If a fact cannot be confirmed, it is marked “Not verified.” No fact from memory alone. This gate exists because agents hallucinate, and hallucinated stats in a published class are permanent.
3. Build. The agent constructs the full section: 10 JSON-LD schemas, meta tags, CSS design system, HTML body with modules, FAQ accordion matching FAQPage schema count exactly, JS IIFE. Output is typically 900-1100 lines of Liquid.
4. Self-audit. Before deploy, a Python script validates: JSON-LD parses, TOC anchors resolve, FAQ count matches schema count, file ends with endschema, no banned terms. If any check fails, the agent fixes and re-runs.
5. Staging deploy. The section and template go to a staging Shopify theme. Render-verify at three viewports with cache-busted URLs.
6. MAIN promotion. GET each file from staging, PUT to MAIN, re-GET from MAIN, assert byte-length parity. If lengths diverge, halt.
7. Page creation + metafields. Create the Shopify page via Admin GraphQL, publish, set SEO metafields (title_tag and description_tag). Query and record createdAt.
8. Image hand-off. OG banner generation is a separate step handled by a different agent. The section ships with a placeholder; the URL is wired in only when the banner passes its own quality gate.

This pipeline has built Classes 71 through 75 of this Academy. It works. The rest of this class teaches you the components you need to build your own version.

Module 02

Authoring a Custom Skill

Build a skill when the same workflow runs more than twice, involves constraints the agent must follow every time, or requires reference material the agent needs to read. If you are repeating the same 15 lines of instructions across prompts, that is a skill.

Directory structure

~/.gemini/config/skills/shopify-dds-mastery/
├── SKILL.md              # Required: frontmatter + instructions
├── scripts/              # Optional: helper scripts
│   └── deploy.ps1
├── references/           # Optional: deep documentation
│   ├── json-ld-schemas.md
│   └── dds-constants.md
└── resources/            # Optional: templates, configs
    └── section-template.liquid

The SKILL.md file

---
name: shopify-dds-mastery
description: |
  Use this skill for ALL work on the Design Delight Studio
  Shopify store (ddsboston.com, Atelier 3.4.0 theme).
  Triggers on any task involving .liquid files, Shopify
  sections, JSON templates, section schema, or the DDS
  store.
---

# Shopify DDS Mastery

## When to Use
- Creating or editing any .liquid section file
- Building page templates for the Academy
- Working with Shopify Admin API (REST or GraphQL)
- Deploying theme assets via deploy.ps1

## Constraints
- All CSS scoped to section ID. No global selectors.
- JS in a single IIFE. No module imports.
- Wrap code blocks containing double-brace or tag syntax in raw/endraw
- SEO Magnet V3: 10 JSON-LD schemas, FAQ count == accordion count
- Brand: gold #FFE069 on #04090c. Playfair Display + DM Sans.
- Permitted certs only: GOTS / GRS / OCS / PETA-Approved Vegan / Fair Trade.

## Deploy Workflow
1. Deploy to staging theme (192259391669)
2. Render-verify cache-busted at 3 viewports
3. Promote to MAIN (191142756533) with length-parity
4. Re-GET from MAIN and confirm

What each part does

• name — must match the folder name exactly. Lowercase, hyphens only.
• description — the trigger clause. Write it from the agent's perspective: “Use this skill when...” This is the most important field because it controls whether the agent activates the skill. Too broad = false triggers. Too narrow = the agent never finds it.
• Body — detailed instructions the agent follows when the skill activates. Keep it under 500 lines. If you need more, put the overflow in a references/ subdirectory and reference it from the body.

Module 03

Trigger Matching

Trigger matching is where most custom skills fail. The description is either too broad (fires on every task) or too narrow (never fires when you need it).

Good vs. bad descriptions

Testing your triggers

1. Install the skill in the correct directory.
2. Open a new Antigravity session (the agent scans skills at startup, not mid-session).
3. Issue a task that should activate the skill. Verify the agent follows your instructions.
4. Issue a task that should not activate it. Verify it stays dormant.
5. If the skill fires incorrectly, narrow the description. If it does not fire, broaden the keywords.

Module 04

Subagent Orchestration

When to use subagents

• Context isolation. A subagent's context window does not pollute the parent. If a research task generates 50KB of raw HTML, that stays in the subagent's context, and only the extracted results come back.
• Parallel execution. You can run a frontend build agent, a backend build agent, and a QA validator agent simultaneously. Each works in its assigned scope.
• Tool specialization. A browser subagent navigates web pages. A filesystem subagent reads and writes files. Each subagent sees only the tools relevant to its task.

The DDS example: image hand-off

In the DDS pipeline, OG banner generation is handled by a separate agent (or a separate step driven by a different model). The build agent produces the section with a placeholder URL. The image agent generates the banner, uploads it, and returns the CDN URL. The build agent then wires the URL and deploys. This is subagent orchestration in practice: two agents with different capabilities, coordinated by the operator.

Module 05

MCP Server Wiring

Configuration locations

• Global: ~/.gemini/config/mcp_config.json — shared across all workspaces.
• Workspace: .agents/mcp_config.json — project-specific servers only.

{
  "mcpServers": {
    "shopify": {
      "command": "npx",
      "args": ["-y", "@anthropic/shopify-mcp-server"],
      "env": {
        "SHOPIFY_STORE_URL": "https://your-store.myshopify.com",
        "SHOPIFY_ACCESS_TOKEN": "${SHOPIFY_TOKEN}"
      }
    },
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@anthropic/filesystem-mcp-server", "/path/to/project"],
      "env": {}
    }
  }
}

What MCP servers expose

• Tools — functions the agent can call. The Shopify MCP server exposes get-products, create-product, update-order. The filesystem server exposes read_file, write_file, search_files.
• Resources — read-only data the agent can query. Schema definitions, documentation, catalog data.
• Prompts — pre-built prompt templates the server provides.

Module 06

Brief Design: Writing What the Agent Executes

The DDS task brief for a class build is typically 200-400 lines. That is not excessive. That is precise. Every line eliminates one possible misinterpretation.

Anatomy of a DDS task brief

1. Scope + assumptions. What this task IS and IS NOT. What the agent should NOT touch. What it can assume exists.
2. Metadata. Class number, handle, section filename, template filename, CSS prefix, section_id pattern.
3. Research gate. What to research, what sources to use, what to mark as “Not verified.”
4. Voice gate. Load dds_voice_core.md. Self-check: “would Robert McCullock actually write this?”
5. Build spec. SEO Magnet V3 requirements in order: preloader kill, Liquid vars, 10 JSON-LD schemas, meta tags, CSS, body structure, speakable IDs, answer capsules, module count, code block rules, cross-link verification, FAQ count gate.
6. OG hand-off. Build with placeholder. Pause. Receive URL. Replace. Deploy.
7. Deploy spec. Staging theme ID. Render-verify. MAIN promote with length parity. Page creation. Metafields. Re-GET verification.
8. Output spec. What to report back: handle, live URL, re-GET values, classes_data row, sources list.

Module 07

Operator Discipline

Five rules of operator discipline

1. Verify against source of truth, never the agent's word. The agent says the file deployed? Pull it from the live system and check. The agent says JSON-LD parses? Run a validator. The agent says the FAQ count matches? Count them yourself. Every claim the agent makes is an assertion that needs evidence.
2. Reversible deploys only. Before every deployment, snapshot the current state. If the deployment breaks something, restore from the snapshot in a single command. If you cannot roll back, you cannot ship. The DDS pipeline saves every overwritten file to a snapshot directory before writing.
3. Hand-off boundaries are non-negotiable. If an agent is unreliable at a subtask (image generation, for example), split that subtask into a separate step with its own quality gate. Do not let a flaky subtask take down the entire pipeline.
4. One source of truth. The live MAIN theme is the source of truth for DDS. Not the staging theme. Not the agent's context. Not the local filesystem copy from three hours ago. When in doubt, pull from MAIN.
5. Gate stacks are mandatory, not optional. Every output passes through truth/sourcing, voice, schema, and deploy gates. If a gate is skipped “just this once,” the output ships with unverified risk. Gates exist because human operators forget things. Let the gates remember for you.

Module 08

Where This Sits in the Antigravity Lane

The progression: onramp teaches you to talk to the agent. First light teaches you to build with it. Platform teaches you to configure it. Multi-model teaches you to choose the right engine. Skill Architect teaches you to build the system itself — the skills, the orchestration, the pipeline that produces the output. This is where the operator stops being a user and becomes the architect.

Module 09

Paste-Ready Templates & Prompts

---
name: my-skill-name
description: |
  Use this skill when [specific task or intent].
  Triggers on [specific keywords, file types, or patterns].
---

# My Skill Name

## When to Use
- [Scenario 1]
- [Scenario 2]

## Constraints
- [Hard rule 1]
- [Hard rule 2]

## Workflow
1. [Step 1]
2. [Step 2]
3. [Step 3]

## Output Format
- [What the output should look like]

{
  "mcpServers": {
    "my-server": {
      "command": "npx",
      "args": ["-y", "@org/my-mcp-server"],
      "env": {
        "API_TOKEN": "${MY_API_TOKEN}"
      }
    }
  }
}

I need three parallel agents for this project:
1. Agent A (frontend): Build the UI components in /src/components/.
   Use React 19, TypeScript strict mode.
2. Agent B (backend): Build the API routes in /src/api/.
   Use Express with input validation on every endpoint.
3. Agent C (QA): After A and B complete, run the test suite
   and report failures with file, line number, and fix suggestion.
Each agent works only in its assigned directory.
No agent modifies files outside its scope.

Write a task brief for building [describe the feature].
The brief must include:
- Scope: what this task IS and IS NOT.
- Metadata: filenames, directory structure, naming conventions.
- Constraints: hard rules the output must follow.
- Gates: validation checks that must pass before the output is accepted.
- Output spec: what to report when done.
No ambiguity. Every constraint eliminates one possible misinterpretation.

Audit all installed skills in this workspace:
1. List every skill by name, location (global vs workspace), and
   description length.
2. Flag skills with descriptions over 200 characters (trigger bloat).
3. Flag skills with descriptions under 20 characters (under-specified).
4. Identify potential trigger conflicts: two skills whose descriptions
   overlap and could both fire on the same task.
5. For each conflict, recommend which skill should own the trigger
   and how to narrow the other.

Frequently Asked Questions

FAQ